From owner-linux-xfs@oss.sgi.com Mon Jan 1 16:01:30 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 16:01:20 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6689 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 16:00:52 -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 QAA08983 for ; Mon, 1 Jan 2001 16:09:23 -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 KAA07097; Tue, 2 Jan 2001 10:59:28 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA06515; Tue, 2 Jan 2001 10:59:19 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101021059.ZM6627@wobbly.melbourne.sgi.com> Date: Tue, 2 Jan 2001 10:59:18 -0400 In-Reply-To: Seth Mos "XFS and root shell" (Dec 20, 12:03am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: XFS and root shell Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Dec 20, 12:03am, Seth Mos wrote: > Subject: XFS and root shell > Hi, > hi Seth, [just catching up on some old mail] > If I have an ext2 filesystem that can not be mounted on boot time it will > bring up a root shell for system maintenance. How difficult is it to make > XFS do the same. > i think the consensus was this shouldn't be too hard. i'll make xfs_repair install into /sbin by default (from its current home in /usr/sbin) shortly. > I booted and older kernel (older style log) did a dirty reboot and the > newer kernel could not mount /home because of the older log style. > Ofcourse xfs_repair nows what to do but i did not notice untill I tried to > log in. > this is really a bit of an unusual one ... the log format change wasn't really corruption (which is what xfs_repair is out to fix), it was a premeditated ondisk format change comparable to the conversion from little to big endian in some ways (there was plenty of mailing-list warnings etc at the time). It is just a coincidence that the new xfs_repair can fix it - it simply blows away the entire (clean, old) log & then inserts a new dummy log record at the log head (ie. creates a new format log). these are the joys of working with beta software i guess. there are no further ondisk changes coming (afaik) though, so this sort of situation shouldn't arise again. i guess what i'm getting at is that this example doesn't really have much to do with a rescue disk after all... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 1 16:23:21 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 16:23:10 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:62480 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 16:22:58 -0800 Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f020Mse02456; Mon, 1 Jan 2001 18:22:54 -0600 (CST) Message-ID: <3A511F53.5481F445@thebarn.com> Date: Mon, 01 Jan 2001 18:22:43 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: HEADS UP 2.4.0-prerelease References: <10101021023.ZM6569@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I have 2.4.0-prerelease compiled and running. If everything holds together I should be able update the current tree sometime tomorrow. I needs run some changes by Ananth first. > --- (fwd) --- > > Subject: Happy new year^H^H^H^Hkernel.. > Date: Sun, 31 Dec 2000 20:25:58 GMT > From: Linus Torvalds > To: Kernel Mailing List > > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some > last-minute stuff that needed fixing (ie the dirty page lists etc), and > the best I can do is make a prerelease. > > There's a 2.4.0-prerelease out there, and this is basically it. I want > people to test it for a while, and I want to give other architectures the > chance to catch up with some of the changes, but read my lips: no more > recounts. There is no "prerelease1", to become "prerelease2" and so on. > > One thing other architectures will want to catch up with is the changes to > handle 2GHz+ machines, which due to overflow issues caused "loops_per_sec" > to become "loops_per_jiffy". And some architectures have not had much > chance to synchronize with me due to other fires to put out. > > Give it your worst. After you recover from being hung-over, of course. > > Linus > ----- > prerelease: > - Alan Cox: more synchronizations > - Manfred Spraul: ptrace/suid-exec race fix > > - pre7: > - x86 LDT handling fixes: revert some cleanups (the LDT really > doesn't act like a TLB context) > - Richard Henderson: alpha update (working memmove() from Ivan > Kokshaysky etc) > - Manfred: winbond-840.c net driver update (fix oops on module unload etc) > - Alan Cox: more synchronizations (with some fixes from Andrew Morton) > > - pre6: > - Marc Joosen: BIOS int15/e820 memory query: don't assume %edx > unchanged by the BIOS. Fixes at least some IBM ThinkPads. > - Alan Cox: synchronize > - Marcelo Tosatti & me: properly sync dirty pages > - Andreas Dilger: proper ext2 compat flag checking > > - pre5: > - NIIBE Yutaka: SuperH update > - Geert Uytterhoeven: m68k update > - David Miller: TCP RTO calc fix, UDP multicast fix etc > - Duncan Laurie: ServerWorks PIRQ routing definition. > - mm PageDirty cleanups, added sanity checks, and don't lose the bit. > > - pre4: > - Christoph Rohland: shmfs cleanup > - Nicolas Pitre: don't forget loop.c flags > - Geert Uytterhoeven: new-style m68k Makefiles > - Neil Brown: knfsd cleanups, raid5 re-org > - Andrea Arkangeli: update to LVM-0.9 > - LC Chang: sis900 driver doc update > - David Miller: netfilter oops fix > - Andrew Grover: acpi update > > - pre3: > - Christian Jullien: smc9194: proper dev_kfree_skb_irq > - Cort Dougan: new-style PowerPC Makefiles > - Andrew Morton, Petr Vandrovec: fix run_task_queue > - Christoph Rohland: shmfs for shared memory handling > > - pre2: > - Kai Germaschewski: ISDN update (including Makefiles) > - Jens Axboe: cdrom updates > - Petr Vandrovec; Matrox G450 support > - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms > - David Miller: sparc (and other) Makefile fixup > - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups) > - Niels Kristian Bech Jensen: checkconfig, USB warnings > - Andrew Grover: large ACPI update > > - pre1: > - me: drop support for old-style Makefiles entirely. Big. > - me: check b_end_io at the IO submission path > - me: fix "ptep_mkdirty()" (so that swapoff() works correctly) > - fix fault case in copy_from_user() with a constant size, where > ((size & 3) == 3)... > > --- (end) --- > > -- > Nathan -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Mon Jan 1 16:29:10 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 16:29:00 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:30053 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 16:28:56 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA14971 for ; Mon, 1 Jan 2001 16:28:04 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA76735 for linux-xfs@oss.sgi.com; Tue, 2 Jan 2001 11:27:35 +1100 (EST) Date: Tue, 2 Jan 2001 11:27:35 +1100 (EST) From: Nathan Scott Message-Id: <200101020027.LAA76735@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmds build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:81364a Date: Mon Jan 1 16:26:39 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/CHANGELOG - 1.8 - document recent changes since 1.0.6 (lvm+mkfs, few minor things). cmd/xfs/VERSION - 1.8 - bump revision number. cmd/xfs/repair/Makefile - 1.45 - install to /sbin, not /usr/sbin. From owner-linux-xfs@oss.sgi.com Mon Jan 1 17:01:51 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 17:01:41 -0800 Received: from smtp5.xs4all.nl ([194.109.6.49]:17104 "EHLO smtp5.xs4all.nl") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 17:01:22 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA03332; Tue, 2 Jan 2001 02:01:20 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA07869; Tue, 2 Jan 2001 02:01:20 +0100 (CET) Date: Tue, 2 Jan 2001 02:01:20 +0100 (CET) From: Seth Mos To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: XFS and root shell In-Reply-To: <10101021059.ZM6627@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 2 Jan 2001, Nathan Scott wrote: > On Dec 20, 12:03am, Seth Mos wrote: > > Subject: XFS and root shell > > Hi, > > > > hi Seth, > > [just catching up on some old mail] > > > If I have an ext2 filesystem that can not be mounted on boot time it will > > bring up a root shell for system maintenance. How difficult is it to make > > XFS do the same. > > > > i think the consensus was this shouldn't be too hard. > i'll make xfs_repair install into /sbin by default (from > its current home in /usr/sbin) shortly. That would be great, and 2.4.0-pre is out! :-) > > I booted and older kernel (older style log) did a dirty reboot and the > > newer kernel could not mount /home because of the older log style. > > Ofcourse xfs_repair nows what to do but i did not notice untill I tried to > > log in. > > > > this is really a bit of an unusual one ... the log format change > wasn't really corruption (which is what xfs_repair is out to > fix), it was a premeditated ondisk format change comparable to > the conversion from little to big endian in some ways (there was > plenty of mailing-list warnings etc at the time). It is just a > coincidence that the new xfs_repair can fix it - it simply blows > away the entire (clean, old) log & then inserts a new dummy log > record at the log head (ie. creates a new format log). I needed a test5 kernel in order to burn CD's. Otherwise I wouldn't even have noticed it. I sent another post about this as well. I have had the kernel get kupdate in a D state (BAD I know). This caused the filesystem to be unable to sync. After that the FS is dirty and can cause the kernel to not be able to recover it on the next boot. That's when I noticed that: 1. It does not drop you to a shell. 2. The xfs_repair binary was not in /sbin 3. A bootdisk with a XFS kernel alone would net help get /usr back 4. I was screwed ;-) In the meanwhile I have taken out 64MB of ram on my home machine and have been unable to reproduce it since. So It appears that one DIMM is somewhat schizo. It is somewhere around the room now, I'm not sure where. I can also rule out power supply problems. (2x300Watt redundant) The complete system is stable since then. I have been unable to get the box to fall over. It even survives Quake3 and all ;-) > these are the joys of working with beta software i guess. there > are no further ondisk changes coming (afaik) though, so this sort > of situation shouldn't arise again. i guess what i'm getting at > is that this example doesn't really have much to do with a rescue > disk after all... Ehm, if you have faulty RAM you still might want to have that rescue disk though. Suppose that you have your root as xfs and something funky happens to your hardware? There happen to be a lot of rescue disks around that have e2fsck ;-) That is the one and only reason I have a ext2 root (also holds /boot) Kind regards and a hacking new year. Seth From owner-linux-xfs@oss.sgi.com Mon Jan 1 17:23:01 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 17:22:51 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48930 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 17:22:36 -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 RAA09784 for ; Mon, 1 Jan 2001 17:31:11 -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 MAA07606; Tue, 2 Jan 2001 12:21:18 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA06994; Tue, 2 Jan 2001 12:21:18 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101021221.ZM6996@wobbly.melbourne.sgi.com> Date: Tue, 2 Jan 2001 12:21:17 -0400 In-Reply-To: Seth Mos "Re: XFS and root shell" (Jan 2, 2:01am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Seth Mos Subject: Re: XFS and root shell Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Seth, On Jan 2, 2:01am, Seth Mos wrote: > Subject: Re: XFS and root shell > > ... > > this is really a bit of an unusual one ... the log format change > > wasn't really corruption (which is what xfs_repair is out to > > fix), it was a premeditated ondisk format change comparable to > > ... i guess what i'm getting at > > is that this example doesn't really have much to do with a rescue > > disk after all... > > Ehm, if you have faulty RAM you still might want to have that rescue disk yes, but thats a different example. ;-) > though. Suppose that you have your root as xfs and something funky happens > to your hardware? yup, sure, you absolutely want a rescue disk in those cases. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 1 17:36:51 2001 Received: by oss.sgi.com id ; Mon, 1 Jan 2001 17:36:41 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:41578 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 1 Jan 2001 17:36:25 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA02526 for ; Mon, 1 Jan 2001 17:36:20 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07665; Tue, 2 Jan 2001 12:35:04 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA07049; Tue, 2 Jan 2001 12:35:01 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101021235.ZM7005@wobbly.melbourne.sgi.com> Date: Tue, 2 Jan 2001 12:35:00 -0400 In-Reply-To: Russell Cattelan "Re: XFS file recovery???" (Dec 21, 11:50am) References: <3A4242D5.A9649B1@thebarn.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Russell Cattelan , Damir Dezeljin Subject: Re: XFS file recovery??? Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Dec 21, 11:50am, Russell Cattelan wrote: > Subject: Re: XFS file recovery??? > Damir Dezeljin wrote: > > > Firstly excuse my poor english. > > I used MediaMail on Indigo2 (Irix6.2), bud my 2Gb (XFS) disk crached - I > > can't reboot from it nother mount it, because it have a lot of bad-sectors, > > so I made an disk image on linux box with "dd of=/dev/sdc of=SGI.dsk > > conv=noerror", but I still can't mount it trought loop device and when I run > > xfs_repair on it, it say that there are no usable superblocks, but when I > > make a search on an image (ex. strings SGI.dsk |grep "dezo@nib.si") I get a > > lot of output, so my files are stil here ... is there any way (progy) to > > recover these files? > If xfs_repair gives up, I don't know of any program to recover from this (other than from a xfsdump/other backup beforehand, of course). > Hmm xfs_repair should scan the file system and hopefully find at least one > valid super block. > > run xfs_db on you file system image. > ... I think xfs_db will fail to start if it can't find the primary superblock. xfs_repair does a pretty thorough job of looking though, so if it doesn't find any superblocks at all, I think its going to be an uphill battle to make any progress on this. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 2 06:47:14 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 06:47:04 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:64094 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 06:46:54 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA09507 for ; Tue, 2 Jan 2001 06:46:02 -0800 (PST) mail_from (raa@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA309154; Tue, 2 Jan 2001 08:45:37 -0600 (CST) Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA92370; Tue, 2 Jan 2001 08:45:37 -0600 (CST) From: "Bob Albers Jr." Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA06573; Tue, 2 Jan 2001 08:45:46 -0600 (CST) Message-Id: <200101021445.IAA06573@ioperf.americas.sgi.com> Date: Tue, 2 Jan 2001 08:45:46 -0600 (CST) To: Nathan Scott , Russell Cattelan Subject: Re: HEADS UP 2.4.0-prerelease Cc: linux-xfs@oss.sgi.com, slinx-xfs@engr.sgi.com References: <10101021023.ZM6569@wobbly.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Did the elevator stall problem fix make into 2.4.0-prerelease? Bob From owner-linux-xfs@oss.sgi.com Tue Jan 2 06:50:34 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 06:50:24 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:33294 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 06:50:20 -0800 Received: from burns.home.kernel.dk ([192.168.0.2] ident=root) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14DSl6-0003EZ-00; Tue, 02 Jan 2001 15:49:52 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14DSl2-0002zg-00; Tue, 02 Jan 2001 15:49:48 +0100 Date: Tue, 2 Jan 2001 15:49:48 +0100 From: Jens Axboe To: "Bob Albers Jr." Cc: Nathan Scott , Russell Cattelan , linux-xfs@oss.sgi.com, slinx-xfs@engr.sgi.com Subject: Re: HEADS UP 2.4.0-prerelease Message-ID: <20010102154948.A11449@suse.de> References: <10101021023.ZM6569@wobbly.melbourne.sgi.com> <200101021445.IAA06573@ioperf.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101021445.IAA06573@ioperf.americas.sgi.com>; from raa@sgi.com on Tue, Jan 02, 2001 at 08:45:46AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Jan 02 2001, Bob Albers Jr. wrote: > Did the elevator stall problem fix make into 2.4.0-prerelease? blk-13 (at least partial merge) is still pending and being discussed. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Tue Jan 2 10:14:34 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 10:14:25 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13386 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 10:14:06 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05540 for ; Tue, 2 Jan 2001 10:22:35 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA07258; Tue, 2 Jan 2001 10:12:41 -0800 (PST) Date: Tue, 2 Jan 2001 10:11:34 -0800 (PST) From: Tom Duffy To: Seth Mos cc: Subject: Re: CD recording under latest CVS 2.4.0-XFS-test12 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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing have you tried: modprobe sg and then cdrecord -scanbus? -tduffy On Wed, 27 Dec 2000, Seth Mos wrote: > Hi, > > Has anyone succeeded in burning CDR's under the latest CVS? > Iam trying to figure out if this is also happened to ther people on this > list. If this is a XFS kernel only problem I don't need make a fool of > myself elsewhere ;-) > > I know it broke around test8 anyways and under XFS-test8 (according > to the linux24 ToDo list http://linux24.sourceforge.net) > > Someone reported it fixed after that, but it is still broken over here. > > Following Specs that _work_ under XFS-test5 > > All scsi > Diamond Fireport 40 (sym53c8xx) > Philips CDD2600 (2x speed writer) > Plextor 32x cdrom > > /proc/scsi/sym53c8xx/0 lists the adapter > /proc/scsi/scsi lists both devices > > cd's are mountable in both drives. > however cdrecord 1.9 doesn't find the writer with 'cdrecord -scanbus' > > cdrecord -scanbus -debug reports FFFFFFFF for every cookie on bus #0 - #15 > > Kind regards > Seth > From owner-linux-xfs@oss.sgi.com Tue Jan 2 16:59:17 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 16:58:58 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3199 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 16:58: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 QAA23331 for ; Tue, 2 Jan 2001 16:57:51 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA316962 for ; Tue, 2 Jan 2001 18:57:25 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA55309 for ; Tue, 2 Jan 2001 18:57:25 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f030vPK12214 for linux-xfs@oss.sgi.com; Tue, 2 Jan 2001 18:57:25 -0600 Date: Tue, 2 Jan 2001 18:57:25 -0600 From: Russell Cattelan Message-Id: <200101030057.f030vPK12214@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 2 16:57:14 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81395a cmd/xfs/misc/mkinitrd.xfs - 1.3 - Update mkinitrd to use new module layout. From owner-linux-xfs@oss.sgi.com Tue Jan 2 17:21:48 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 17:21:38 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:48135 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 17:21:27 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA25716 for ; Tue, 2 Jan 2001 17:20:34 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id MAA29889; Wed, 3 Jan 2001 12:20:04 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - In-reply-to: Your message of "Tue, 02 Jan 2001 18:57:25 MDT." <200101030057.f030vPK12214@gibble.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 12:20:04 +1100 Message-ID: <6410.978484804@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 2 Jan 2001 18:57:25 -0600, Russell Cattelan wrote: >Date: Tue Jan 2 16:57:14 PST 2001 >Modid: 2.4.x-xfs:slinx:81395a >cmd/xfs/misc/mkinitrd.xfs - 1.3 > - Update mkinitrd to use new module layout. Instead of hardcoding module paths into mkinitrd and changing the script when modules move, it is better to run as (untested) mkinitrd --with=pagebuf --with=xfs_support --with=xfs From owner-linux-xfs@oss.sgi.com Tue Jan 2 17:37:38 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 17:37:28 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:27226 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 17:37:06 -0800 Received: from sydney.sydney.sgi.com ([134.14.48.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA00277 for ; Tue, 2 Jan 2001 17:36:55 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id MAA00675; Wed, 3 Jan 2001 12:35:32 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: TAKE - In-reply-to: Your message of "Wed, 03 Jan 2001 12:20:04 +1100." <6410.978484804@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 12:35:31 +1100 Message-ID: <6606.978485731@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 03 Jan 2001 12:20:04 +1100, Keith Owens wrote: >On Tue, 2 Jan 2001 18:57:25 -0600, >Russell Cattelan wrote: >>Date: Tue Jan 2 16:57:14 PST 2001 >>Modid: 2.4.x-xfs:slinx:81395a >>cmd/xfs/misc/mkinitrd.xfs - 1.3 >> - Update mkinitrd to use new module layout. > >Instead of hardcoding module paths into mkinitrd and changing the >script when modules move, it is better to run as (untested) > >mkinitrd --with=pagebuf --with=xfs_support --with=xfs Forgot to mention. Instead of commenting out these lines # echo "No module $modName found for kernel $kernel" >&2 # exit 1 you can precede a module name with '-' to suppress errors. No need to hack the script. From owner-linux-xfs@oss.sgi.com Tue Jan 2 17:46:27 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 17:46:17 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5232 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 17:46:11 -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 RAA03820 for ; Tue, 2 Jan 2001 17:54:48 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA319107; Tue, 2 Jan 2001 19:44:52 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA43291; Tue, 2 Jan 2001 19:44:52 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id f031iqZ12552; Tue, 2 Jan 2001 19:44:52 -0600 Message-ID: <3A528413.674FC751@thebarn.com> Date: Tue, 02 Jan 2001 19:44:51 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test13-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: TAKE - References: <6410.978484804@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Keith Owens wrote: > On Tue, 2 Jan 2001 18:57:25 -0600, > Russell Cattelan wrote: > >Date: Tue Jan 2 16:57:14 PST 2001 > >Modid: 2.4.x-xfs:slinx:81395a > >cmd/xfs/misc/mkinitrd.xfs - 1.3 > http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/>cmd/xfs/misc/mkinitrd.xfs.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>cmd/xfs/misc/mkinitrd.xfs.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h > > - Update mkinitrd to use new module layout. > > Instead of hardcoding module paths into mkinitrd and changing the > script when modules move, it is better to run as (untested) > > mkinitrd --with=pagebuf --with=xfs_support --with=xfs I remember trying that at one point without much luck... although I don't remember why. Ohh that's right... the size of the ramdisk has to be significantly increased... from 4092 to 25000 Actually I need these changes for the modified RH 7.0 installer. It's much easier to install a modified mkinitrd than more fiddling with anaconda. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Jan 2 17:47:47 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 17:47:38 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6512 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 17:47:29 -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 RAA00567 for ; Tue, 2 Jan 2001 17:56:06 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA318042 for ; Tue, 2 Jan 2001 19:46:13 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA62417 for ; Tue, 2 Jan 2001 19:46:12 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f031kDP12607 for linux-xfs@oss.sgi.com; Tue, 2 Jan 2001 19:46:13 -0600 Date: Tue, 2 Jan 2001 19:46:13 -0600 From: Russell Cattelan Message-Id: <200101030146.f031kDP12607@gibble.americas.sgi.com> Subject: TAKE - It's 2.4.0-prerelease! To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 2 17:43:05 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-PR The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81397a linux/drivers/atm/firestream.c - 1.1 linux/drivers/acpi/power.c - 1.1 linux/include/asm-m68k/contregs.h - 1.1 linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.1 linux/drivers/scsi/osst_options.h - 1.1 linux/drivers/scsi/osst_detect.h - 1.1 linux/Documentation/DocBook/sis900.tmpl - 1.1 linux/drivers/acpi/ec.h - 1.1 linux/Documentation/i2c/functionality - 1.1 linux/drivers/scsi/osst.h - 1.1 linux/include/asm-m68k/fbio.h - 1.1 linux/drivers/scsi/osst.c - 1.1 linux/arch/m68k/ifpsp060/src/README-SRC - 1.1 linux/drivers/atm/firestream.h - 1.1 linux/arch/m68k/ifpsp060/src/fplsp.S - 1.1 linux/arch/m68k/ifpsp060/src/fpsp.S - 1.1 linux/drivers/scsi/README.osst - 1.1 linux/include/asm-m68k/idprom.h - 1.1 linux/include/asm-m68k/kbio.h - 1.1 linux/arch/m68k/ifpsp060/src/ftest.S - 1.1 linux/arch/m68k/ifpsp060/src/itest.S - 1.1 linux/arch/m68k/ifpsp060/src/ilsp.S - 1.1 linux/arch/alpha/lib/ev67-strrchr.S - 1.1 linux/arch/m68k/ifpsp060/src/isp.S - 1.1 linux/include/asm-m68k/vuid_event.h - 1.1 linux/scripts/Configure - 1.11 linux/net/x25/af_x25.c - 1.18 linux/net/rose/rose_timer.c - 1.3 linux/net/rose/rose_subr.c - 1.3 linux/net/rose/rose_route.c - 1.6 linux/net/rose/rose_out.c - 1.3 linux/net/rose/rose_loopback.c - 1.5 linux/net/rose/rose_link.c - 1.5 linux/net/rose/rose_in.c - 1.3 linux/net/rose/rose_dev.c - 1.6 linux/net/rose/af_rose.c - 1.17 linux/net/netrom/nr_timer.c - 1.4 linux/net/netrom/nr_subr.c - 1.3 linux/net/netrom/nr_route.c - 1.7 linux/net/netrom/nr_out.c - 1.3 linux/net/netrom/nr_loopback.c - 1.6 linux/net/netrom/nr_in.c - 1.3 linux/net/netrom/nr_dev.c - 1.6 linux/net/netrom/af_netrom.c - 1.16 linux/net/ipv4/udp.c - 1.20 linux/net/ipv4/tcp_input.c - 1.21 linux/net/ipv4/ipconfig.c - 1.15 linux/net/ipv4/ip_fragment.c - 1.11 linux/net/ipv4/af_inet.c - 1.23 linux/net/core/sock.c - 1.17 linux/net/core/skbuff.c - 1.17 linux/net/ax25/ax25_uid.c - 1.6 linux/net/ax25/ax25_timer.c - 1.5 linux/net/ax25/ax25_subr.c - 1.5 linux/net/ax25/ax25_std_timer.c - 1.3 linux/net/ax25/ax25_std_subr.c - 1.3 linux/net/ax25/ax25_std_in.c - 1.3 linux/net/ax25/ax25_route.c - 1.7 linux/net/ax25/ax25_out.c - 1.7 linux/net/ax25/ax25_ip.c - 1.6 linux/net/ax25/ax25_in.c - 1.7 linux/net/ax25/ax25_iface.c - 1.4 linux/net/ax25/ax25_ds_timer.c - 1.3 linux/net/ax25/ax25_ds_subr.c - 1.4 linux/net/ax25/ax25_ds_in.c - 1.4 linux/net/ax25/ax25_dev.c - 1.4 linux/net/ax25/ax25_addr.c - 1.3 linux/net/ax25/af_ax25.c - 1.17 linux/mm/vmscan.c - 1.42 linux/mm/swapfile.c - 1.27 linux/mm/swap_state.c - 1.22 linux/mm/mremap.c - 1.20 linux/mm/mprotect.c - 1.14 linux/mm/mmap.c - 1.31 linux/mm/mlock.c - 1.13 linux/mm/memory.c - 1.41 linux/mm/filemap.c - 1.61 linux/kernel/softirq.c - 1.8 linux/kernel/printk.c - 1.11 linux/kernel/ksyms.c - 1.69 linux/kernel/kmod.c - 1.13 linux/kernel/fork.c - 1.26 linux/kernel/Makefile - 1.23 linux/ipc/shm.c - 1.44 linux/init/main.c - 1.47 linux/include/net/tcp.h - 1.21 linux/include/net/sock.h - 1.20 linux/include/net/ax25.h - 1.7 linux/include/linux/zorro.h - 1.6 linux/include/linux/wireless.h - 1.5 linux/include/linux/watchdog.h - 1.3 linux/include/linux/tty.h - 1.14 linux/include/linux/slab.h - 1.12 linux/include/linux/shm.h - 1.12 linux/include/linux/pci.h - 1.38 linux/include/linux/pagemap.h - 1.21 linux/include/linux/mtio.h - 1.3 linux/include/linux/mm.h - 1.43 linux/include/linux/major.h - 1.23 linux/include/linux/init.h - 1.11 linux/include/linux/i2c.h - 1.11 linux/include/linux/fs.h - 1.73 linux/include/linux/ext2_fs_sb.h - 1.5 linux/include/linux/ext2_fs.h - 1.13 linux/include/linux/dtlk.h - 1.3 linux/include/linux/delay.h - 1.3 linux/include/linux/blk.h - 1.18 linux/include/asm-sparc64/processor.h - 1.14 linux/include/asm-sparc/processor.h - 1.11 linux/include/asm-sparc/contregs.h - 1.3 linux/include/asm-ppc/processor.h - 1.21 linux/include/asm-mips/processor.h - 1.13 linux/include/asm-m68k/semaphore-helper.h - 1.3 linux/include/asm-m68k/processor.h - 1.11 linux/include/asm-m68k/mmu_context.h - 1.9 linux/include/asm-m68k/ide.h - 1.4 linux/include/asm-m68k/hardirq.h - 1.7 linux/include/asm-m68k/dvma.h - 1.5 linux/include/asm-i386/processor.h - 1.22 linux/include/asm-i386/mmu_context.h - 1.12 linux/include/asm-i386/delay.h - 1.3 linux/include/asm-arm/processor.h - 1.15 linux/include/asm-alpha/processor.h - 1.11 linux/fs/vfat/namei.c - 1.17 linux/fs/smbfs/file.c - 1.17 linux/fs/romfs/inode.c - 1.19 linux/fs/qnx4/inode.c - 1.20 linux/fs/ntfs/fs.c - 1.24 linux/fs/nls/Config.in - 1.6 linux/fs/nfsd/vfs.c - 1.31 linux/fs/nfsd/nfs3xdr.c - 1.16 linux/fs/nfs/write.c - 1.23 linux/fs/nfs/read.c - 1.20 linux/fs/nfs/file.c - 1.18 linux/fs/ncpfs/symlink.c - 1.12 linux/fs/namei.c - 1.24 linux/fs/isofs/rock.c - 1.11 linux/fs/inode.c - 1.34 linux/fs/hfs/inode.c - 1.11 linux/fs/fat/inode.c - 1.19 linux/fs/ext2/super.c - 1.15 linux/fs/ext2/inode.c - 1.24 linux/fs/ext2/balloc.c - 1.12 linux/fs/exec.c - 1.36 linux/fs/coda/symlink.c - 1.11 linux/fs/coda/inode.c - 1.11 linux/fs/coda/file.c - 1.12 linux/fs/coda/dir.c - 1.18 linux/fs/buffer.c - 1.49 linux/fs/affs/symlink.c - 1.11 linux/fs/affs/file.c - 1.13 linux/fs/adfs/inode.c - 1.15 linux/drivers/zorro/Makefile - 1.6 linux/drivers/video/amifb.c - 1.14 linux/drivers/usb/usb.c - 1.43 linux/drivers/sound/wavfront.c - 1.12 linux/drivers/sound/sonicvibes.c - 1.28 linux/drivers/sound/sb_card.c - 1.22 linux/drivers/sound/mad16.c - 1.12 linux/drivers/sound/es1371.c - 1.28 linux/drivers/sound/es1370.c - 1.27 linux/drivers/scsi/tmscsim.h - 1.5 linux/drivers/scsi/tmscsim.c - 1.9 linux/drivers/scsi/st.c - 1.28 linux/drivers/scsi/scsiiom.c - 1.4 linux/drivers/scsi/scsi.h - 1.18 linux/drivers/scsi/pci2220i.c - 1.14 linux/drivers/scsi/pci2000.c - 1.14 linux/drivers/scsi/ibmmca.h - 1.5 linux/drivers/scsi/ibmmca.c - 1.10 linux/drivers/scsi/eata_dma.c - 1.14 linux/drivers/scsi/dc390.h - 1.5 linux/drivers/scsi/amiga7xx.c - 1.7 linux/drivers/scsi/aha152x.c - 1.16 linux/drivers/scsi/README.tmscsim - 1.4 linux/drivers/scsi/README.ibmmca - 1.4 linux/drivers/scsi/Makefile - 1.23 linux/drivers/scsi/Config.in - 1.18 linux/drivers/sbus/Makefile - 1.5 linux/drivers/pci/quirks.c - 1.18 linux/drivers/net/rcpci45.c - 1.14 linux/drivers/net/ni52.c - 1.10 linux/drivers/net/ni5010.c - 1.9 linux/drivers/net/mace.c - 1.9 linux/drivers/net/lance.c - 1.15 linux/drivers/net/hydra.c - 1.10 linux/drivers/net/hamradio/mkiss.c - 1.8 linux/drivers/net/hamradio/bpqether.c - 1.14 linux/drivers/net/atarilance.c - 1.6 linux/drivers/net/acenic_firmware.h - 1.10 linux/drivers/net/acenic.h - 1.11 linux/drivers/net/acenic.c - 1.22 linux/drivers/net/Makefile - 1.37 linux/drivers/net/Config.in - 1.33 linux/drivers/net/3c523.c - 1.12 linux/drivers/isdn/sc/Makefile - 1.4 linux/drivers/isdn/pcbit/Makefile - 1.4 linux/drivers/isdn/isdnloop/Makefile - 1.4 linux/drivers/isdn/isdn_common.c - 1.18 linux/drivers/isdn/isdn_cards.c - 1.8 linux/drivers/isdn/icn/Makefile - 1.4 linux/drivers/isdn/hisax/Makefile - 1.8 linux/drivers/isdn/avmb1/Makefile - 1.11 linux/drivers/isdn/act2000/Makefile - 1.5 linux/drivers/isdn/Makefile - 1.7 linux/drivers/isdn/Config.in - 1.13 linux/drivers/char/tty_io.c - 1.26 linux/drivers/char/pcxx.c - 1.10 linux/drivers/char/mem.c - 1.30 linux/drivers/char/epca.c - 1.12 linux/drivers/char/dtlk.c - 1.11 linux/drivers/char/Makefile - 1.39 linux/drivers/char/Config.in - 1.40 linux/drivers/cdrom/cdrom.c - 1.27 linux/drivers/block/loop.c - 1.27 linux/drivers/block/ll_rw_blk.c - 1.57 linux/drivers/block/acsi.c - 1.10 linux/arch/ppc/amiga/Makefile - 1.6 linux/arch/m68k/sun3x/Makefile - 1.3 linux/arch/m68k/q40/Makefile - 1.3 linux/arch/m68k/mvme16x/Makefile - 1.4 linux/arch/m68k/mvme147/Makefile - 1.3 linux/arch/m68k/mm/Makefile - 1.4 linux/arch/m68k/mac/Makefile - 1.5 linux/arch/m68k/lib/Makefile - 1.7 linux/arch/m68k/kernel/setup.c - 1.10 linux/arch/m68k/kernel/Makefile - 1.8 linux/arch/m68k/hp300/Makefile - 1.3 linux/arch/m68k/bvme6000/Makefile - 1.3 linux/arch/m68k/atari/Makefile - 1.4 linux/arch/m68k/apollo/Makefile - 1.4 linux/arch/m68k/amiga/Makefile - 1.3 linux/arch/i386/math-emu/fpu_system.h - 1.4 linux/arch/i386/lib/delay.c - 1.5 linux/arch/i386/kernel/time.c - 1.15 - Update to 2.4.0-prerelease linux/arch/i386/kernel/smp.c - 1.30 - 2.4.0-prerelease Update to 2.4.0-prerelease linux/arch/i386/kernel/setup.c - 1.41 - .Update to 2.4.0-prerelease ./ linux/arch/i386/kernel/process.c - 1.29 - ... linux/arch/i386/kernel/Makefile - 1.21 linux/arch/i386/defconfig - 1.50 linux/arch/i386/config.in - 1.53 linux/arch/i386/boot/setup.S - 1.18 linux/arch/alpha/math-emu/Makefile - 1.5 linux/arch/alpha/lib/Makefile - 1.10 linux/arch/alpha/config.in - 1.28 linux/Makefile - 1.77 linux/MAINTAINERS - 1.51 linux/Documentation/video4linux/bttv/README - 1.11 linux/Documentation/sound/Soundblaster - 1.5 linux/Documentation/modules.txt - 1.5 linux/Documentation/devices.txt - 1.8 linux/Documentation/Configure.help - 1.68 linux/Documentation/Changes - 1.29 linux/CREDITS - 1.47 linux/fs/hpfs/namei.c - 1.12 linux/fs/hpfs/file.c - 1.13 linux/fs/efs/symlink.c - 1.9 linux/drivers/sound/cmpci.c - 1.21 linux/drivers/net/irda/smc-ircc.c - 1.16 linux/drivers/isdn/eicon/Makefile - 1.4 linux/Documentation/kernel-parameters.txt - 1.10 linux/drivers/net/arlan.c - 1.13 linux/drivers/net/hamradio/yam.c - 1.12 linux/drivers/char/sx.c - 1.15 linux/drivers/char/generic_serial.c - 1.10 linux/drivers/sound/esssolo1.c - 1.24 linux/fs/partitions/check.c - 1.20 linux/drivers/isdn/divert/Makefile - 1.3 linux/arch/m68k/math-emu/Makefile - 1.4 linux/drivers/net/sis900.c - 1.18 linux/drivers/net/fc/tach_structs.h - 1.2 linux/drivers/net/fc/iph5526.c - 1.10 linux/drivers/atm/nicstar.c - 1.11 linux/drivers/atm/horizon.c - 1.9 linux/drivers/atm/atmtcp.c - 1.7 linux/drivers/atm/atmdev_init.c - 1.7 linux/drivers/atm/ambassador.c - 1.11 linux/drivers/atm/Config.in - 1.8 linux/net/atm/signaling.c - 1.6 linux/net/atm/resources.c - 1.4 linux/net/atm/proc.c - 1.11 linux/net/atm/lec.c - 1.9 linux/net/atm/common.c - 1.7 linux/net/atm/addr.c - 1.4 linux/include/linux/atmdev.h - 1.7 linux/include/linux/atm_tcp.h - 1.4 linux/arch/sh/mm/Makefile - 1.4 linux/arch/sh/lib/Makefile - 1.6 linux/arch/sh/kernel/sh_ksyms.c - 1.4 linux/arch/sh/kernel/setup.c - 1.10 linux/arch/sh/kernel/ptrace.c - 1.6 linux/arch/sh/kernel/Makefile - 1.9 linux/arch/sh/Makefile - 1.6 linux/drivers/sound/maestro.c - 1.19 linux/include/asm-sh/processor.h - 1.10 linux/drivers/pcmcia/cs.c - 1.25 linux/drivers/net/sun3lance.c - 1.4 linux/arch/m68k/sun3/sun3ints.c - 1.3 linux/arch/m68k/sun3/mmu_emu.c - 1.3 linux/arch/m68k/sun3/dvma.c - 1.2 linux/arch/m68k/sun3/config.c - 1.4 linux/arch/m68k/sun3/Makefile - 1.5 linux/arch/m68k/mm/sun3mmu.c - 1.4 linux/arch/m68k/kernel/sun3-head.S - 1.3 linux/arch/m68k/kernel/semaphore.c - 1.5 linux/fs/udf/file.c - 1.21 linux/fs/udf/symlink.c - 1.10 linux/include/asm-m68k/intersil.h - 1.2 linux/drivers/net/pcmcia/ray_cs.h - 1.5 linux/drivers/net/pcmcia/Makefile - 1.14 linux/include/linux/acpi.h - 1.18 linux/drivers/net/wan/cosa.c - 1.16 linux/drivers/net/ncr885e.h - 1.2 linux/drivers/net/ncr885e.c - 1.9 linux/arch/i386/kernel/smpboot.c - 1.20 linux/drivers/scsi/sim710.c - 1.7 linux/drivers/net/sis900.h - 1.7 linux/drivers/scsi/sun3_scsi.c - 1.6 linux/drivers/pci/pci.ids - 1.25 linux/Documentation/networking/sis900.txt - 1.5 linux/drivers/sound/trident.c - 1.18 linux/include/linux/agp_backend.h - 1.8 linux/drivers/char/agp/agpgart_be.c - 1.13 linux/drivers/char/agp/agp.h - 1.9 linux/include/linux/i2c-id.h - 1.8 linux/drivers/i2c/i2c-algo-pcf.c - 1.7 linux/drivers/i2c/i2c-dev.c - 1.8 linux/drivers/i2c/i2c-core.c - 1.9 linux/include/linux/i2c-dev.h - 1.5 linux/Documentation/video4linux/bttv/Modules.conf - 1.2 linux/Documentation/video4linux/bttv/Insmod-options - 1.7 linux/arch/i386/kernel/acpi.c - 1.22 linux/fs/cramfs/inode.c - 1.13 linux/include/linux/telephony.h - 1.4 linux/include/linux/ixjuser.h - 1.3 linux/drivers/telephony/ixj.h - 1.3 linux/drivers/telephony/ixj.c - 1.10 linux/drivers/net/oaknet.c - 1.6 linux/drivers/net/mac89x0.c - 1.3 linux/drivers/atm/iphase.c - 1.7 linux/drivers/sound/via82cxxx_audio.c - 1.10 linux/drivers/net/gmac.c - 1.7 linux/include/linux/raid/md_k.h - 1.9 linux/include/asm-ia64/processor.h - 1.8 linux/drivers/scsi/sun3_NCR5380.c - 1.2 linux/drivers/net/8139too.c - 1.15 linux/drivers/isdn/hysdn/Makefile - 1.4 linux/include/linux/lvm.h - 1.4 linux/fs/lockd/xdr4.c - 1.5 linux/net/bridge/br_input.c - 1.6 linux/drivers/net/tulip/tulip_core.c - 1.15 linux/drivers/net/tulip/tulip.h - 1.8 linux/drivers/net/tulip/timer.c - 1.6 linux/drivers/net/tulip/eeprom.c - 1.6 linux/include/asm-mips64/processor.h - 1.8 linux/drivers/atm/fore200e.c - 1.8 linux/drivers/net/appletalk/ltpc.c - 1.7 linux/drivers/net/appletalk/cops.c - 1.7 linux/drivers/char/sh-sci.c - 1.9 linux/drivers/ide/ide-tape.c - 1.8 linux/drivers/ide/ide-floppy.c - 1.4 linux/drivers/ide/ide-cd.c - 1.9 linux/drivers/ide/Config.in - 1.10 linux/Documentation/sound/ALS - 1.3 linux/Documentation/DocBook/Makefile - 1.11 linux/scripts/kernel-doc - 1.7 linux/include/linux/generic_serial.h - 1.2 linux/Documentation/DocBook/kernel-api.tmpl - 1.7 linux/arch/i386/kernel/pci-irq.c - 1.9 linux/fs/ramfs/inode.c - 1.10 linux/drivers/sound/i810_audio.c - 1.6 linux/include/linux/raid/raid5.h - 1.3 linux/include/asm-s390/processor.h - 1.4 linux/Documentation/DocBook/kernel-locking.tmpl - 1.3 linux/drivers/net/stnic.c - 1.5 linux/arch/i386/kernel/msr.c - 1.6 linux/arch/i386/kernel/cpuid.c - 1.3 linux/arch/i386/kdb/kdba_io.c - 1.9 linux/kdb/modules/kdbm_pg.c - 1.25 linux/fs/pagebuf/page_buf_io.c - 1.38 linux/drivers/acpi/sys.c - 1.4 linux/drivers/acpi/parser/psparse.c - 1.4 linux/drivers/acpi/parser/psargs.c - 1.4 linux/drivers/acpi/namespace/nssearch.c - 1.4 linux/fs/jffs/inode-v23.c - 1.4 linux/drivers/acpi/namespace/nsaccess.c - 1.4 linux/drivers/acpi/interpreter/amutils.c - 1.4 linux/drivers/sound/ymf_sb.c - 1.5 linux/drivers/acpi/interpreter/amprep.c - 1.4 linux/drivers/acpi/interpreter/ammonad.c - 1.4 linux/drivers/acpi/include/actypes.h - 1.4 linux/drivers/acpi/include/acpixf.h - 1.4 linux/drivers/acpi/include/acpiosxf.h - 1.4 linux/drivers/acpi/hardware/hwregs.c - 1.4 linux/drivers/acpi/hardware/hwacpi.c - 1.4 linux/drivers/acpi/events/evxfregn.c - 1.4 linux/drivers/acpi/events/evregion.c - 1.4 linux/drivers/acpi/events/evevent.c - 1.4 linux/drivers/acpi/ec.c - 1.4 linux/drivers/acpi/driver.h - 1.3 linux/drivers/acpi/driver.c - 1.6 linux/drivers/acpi/dispatcher/dswstate.c - 1.4 linux/drivers/acpi/common/cmobject.c - 1.4 linux/drivers/acpi/common/cminit.c - 1.4 linux/drivers/acpi/common/cmcopy.c - 1.4 linux/drivers/acpi/Makefile - 1.4 linux/drivers/mtd/cfi_probe.c - 1.3 linux/arch/sh/boot/compressed/head.S - 1.3 linux/include/net/tcp_ecn.h - 1.2 linux/drivers/media/video/bttv.h - 1.4 linux/drivers/media/video/bttv-driver.c - 1.5 linux/drivers/media/video/bttv-cards.c - 1.4 linux/drivers/media/radio/radio-gemtek.c - 1.4 linux/drivers/media/Makefile - 1.3 linux/drivers/char/i810-tco.c - 1.3 linux/drivers/md/lvm.c - 1.5 linux/drivers/md/raid5.c - 1.6 linux/drivers/acpi/include/acevents.h - 1.3 linux/drivers/acpi/include/aclocal.h - 1.3 linux/drivers/acpi/include/acmacros.h - 1.3 linux/drivers/acpi/include/acnamesp.h - 1.3 linux/drivers/md/lvm-snap.c - 1.2 linux/drivers/net/winbond-840.c - 1.3 linux/drivers/sound/cs4281.c - 1.4 linux/drivers/net/tulip/ChangeLog - 1.2 linux/drivers/media/video/bttvp.h - 1.2 linux/arch/alpha/lib/ev6-memcpy.S - 1.2 linux/arch/alpha/lib/memmove.S - 1.2 linux/include/asm-parisc/processor.h - 1.3 linux/drivers/acpi/ksyms.c - 1.2 linux/drivers/acpi/include/aclinux.h - 1.2 linux/drivers/acpi/cmbatt.c - 1.2 linux/mm/shmem.c - 1.2 - Update to 2.4.0-prerelease From owner-linux-xfs@oss.sgi.com Tue Jan 2 17:59:07 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 17:58:47 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29808 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 17:58:28 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA04178 for ; Tue, 2 Jan 2001 18:07:04 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id MAA02027; Wed, 3 Jan 2001 12:56:54 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Russell Cattelan cc: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: TAKE - In-reply-to: Your message of "Tue, 02 Jan 2001 19:44:51 MDT." <3A528413.674FC751@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 12:56:53 +1100 Message-ID: <6850.978487013@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 02 Jan 2001 19:44:51 -0600, Russell Cattelan wrote: >It's much easier to install a modified mkinitrd than more fiddling with anaconda. If you go that route, adding this line at the start is cleaner basicmodules="-pagebuf -xfs_support -xfs" and remove the comments on # echo "No module $modName found for kernel $kernel" >&2 # exit 1 Minimal maintainence in the future. From owner-linux-xfs@oss.sgi.com Tue Jan 2 19:03:07 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 19:02:58 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32622 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 19:02:47 -0800 Received: from info.engr.sgi.com ([192.26.80.216]) 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 TAA01293; Tue, 2 Jan 2001 19:02:46 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA04447; Tue, 2 Jan 2001 19:02:45 -0800 (PST) Date: Tue, 2 Jan 2001 19:02:45 -0800 (PST) Message-Id: <200101030302.TAA04447@info.engr.sgi.com> X-Pv-Incident: 811526 webPV: proxy2.melbourne.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@odin.corp.sgi.com (dxm@engr.sgi.com) Subject: BUG 811526 - assert trip with kiocluster & loopback To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=811526 Submitter : dxm Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 3 Project : xfs-linux Status : open Description : Test 049 (xfs on loop) causes an assertion to be tripped when running with "-o kiocluster". This is quite repeatable, and I haven't been able to recreate with either "-o kio" or no "-o" option. Today is the first time I've tried 049 with kiocluster (due to it failing earlier in the test due to a qa bug). The problem occurs when running fsstress on an XFS FS loopback mounted from an ext2 FS. (scsi, smp, 1200, small mem) XFS (dev: 7/0) mounting with KIOBUFIO (clustering) Start mounting filesystem: loop(7,0) Ending clean XFS mount for filesystem: loop(7,0) XFS assertion failed: ismrlocked(&ip->i_iolock, MR_ACCESS | MR_UPDATE) != 0, file: xfs_lrw.c, line: 833 kernel BUG at debug.c:48! Entering kdb (current=0xc2e9a000, pid 19815) on processor 1 Panic: invalid operand due to panic @ 0xc8828da5 eax = 0x0000001a ebx = 0xc6886910 ecx = 0x00000001 edx = 0x00000000 esi = 0x00000002 edi = 0x00000002 esp = 0xc2e9bad8 eip = 0xc8828da5 ebp = 0xc2e9bae4 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc2e9baa4 [1]kdb> bt EBP EIP Function(args) 0xc2e9bae4 0xc8828da5 [xfs_support]assfail+0x2d (0xc89b6ee0, 0xc89b6b97, 0x341) xfs_support .text 0xc8828060 0xc8828d78 0xc8828dac 0xc2e9bb10 0xc8999671 [xfs]xfs_bmap+0x1bd (0xc6886928, 0x2c000, 0x0, 0x1000, 0x2) xfs .text 0xc8927060 0xc89994b4 0xc899983c 0xc2e9bb44 0xc8997ede [xfs]linvfs_pb_bmap+0x6e (0xc3daac80, 0x2c000, 0x0, 0x1000, 0xc2e9bb94) xfs .text 0xc8927060 0xc8997e70 0xc8997eec 0xc2e9bbb0 0xc883251e [pagebuf]__pb_block_prepare_write_async+0x7a (0xc3daac80, 0xc10e8940, 0x800, 0xc00, 0x0) pagebuf .text 0xc882e060 0xc88324a4 0xc88326e4 0xc2e9bbe8 0xc8832742 [pagebuf]pagebuf_prepare_write+0x5e (0xc67ea240, 0xc10e8940, 0x800, 0xc00) pagebuf .text 0xc882e060 0xc88326e4 0xc883274c 0xc2e9bc44 0xc0171e86 lo_send+0xba (0xc7f9e0cc, 0xc2d8a800, 0x400, 0x2c800, 0x0) kernel .text 0xc0100000 0xc0171dcc 0xc0171fac 0xc2e9bcb8 0xc01723bf do_lo_request+0x313 (0xc0374334) kernel .text 0xc0100000 0xc01720ac 0xc01724cc 0xc2e9bd00 0xc0167f4c __make_request+0x61c (0xc0374334, 0x1, 0xc5f236c0, 0x0, 0x701) kernel .text 0xc0100000 0xc0167930 0xc0167fc0 0xc2e9bd44 0xc01680ff generic_make_request+0x13f (0x1, 0xc5f236c0, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0167fc0 0xc0168188 0xc2e9bd68 0xc01681e8 submit_bh+0x60 (0x1, 0xc5f236c0) kernel .text 0xc0100000 0xc0168188 0xc01681f0 0xc2e9bd94 0xc016839a ll_rw_block+0x15e (0x1, 0x1, 0xc2e9bdb8, 0xc52635a0) kernel .text 0xc0100000 0xc016823c 0xc0168418 0xc2e9bf74 0xc0135480 fsync_inode_buffers+0xc4 (0xc7671c80) kernel .text 0xc0100000 0xc01353bc 0xc0135564 0xc2e9bf88 0xc01577a6 ext2_fsync_inode+0xe (0xc7671c80, 0x0) kernel .text 0xc0100000 0xc0157798 0xc01577e0 0xc2e9bf98 0xc0157793 ext2_sync_file+0x13 (0xc52635a0, 0xc4adde40, 0x0, 0xc2e9a000) kernel .text 0xc0100000 0xc0157780 0xc0157798 0xc2e9bfbc 0xc0134a88 sys_fsync+0x54 (0x3, 0xbffff9c0, 0x804d8b8, 0x4000ae60, 0xbffffb6c) kernel .text 0xc0100000 0xc0134a34 0xc0134aac 0xc0109047 system_call+0x33 kernel .text 0xc0100000 0xc0109014 0xc010904c From owner-linux-xfs@oss.sgi.com Tue Jan 2 20:26:27 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 20:26:08 -0800 Received: from 209-161-7-107.gargoylecc.com ([209.161.7.107]:10368 "EHLO localhost.localdomain") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 20:25:49 -0800 Received: from localhost (IDENT:ringram@gargoyle [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id VAA00837 for ; Tue, 2 Jan 2001 21:28:02 -0700 Date: Tue, 2 Jan 2001 21:28:02 -0700 (MST) From: Russ Ingram X-Sender: ringram@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition In-Reply-To: <3A4EC96C.2FA6DD32@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is not in direct reference to the Root XFS partition thread, but... Has anyone got a system running with all XFS filesystems (i.e. /boot / /usr ...) and if so is there a HOWTO on how it was done. If there is no HOWTO could someone possibly post an outline of the steps. I would then be happy to write up a HOWTO for someone to post to the http://oss.sgi.com/projects/xfs site (or wherever would be most apropriate). I would like to have such a doc for myself and can only imagine how much easier it will make it for others who would like to create a similar system. Thanx, Russ Russ Ingram Gargoyle Computer Consulting (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 21:00:28 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 21:00:18 -0800 Received: from garnet.sover.net ([209.198.87.53]:48322 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 21:00:07 -0800 Received: from [192.168.1.3] (pm1a8.stj.sover.net [209.198.94.8]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id XAA29790; Tue, 2 Jan 2001 23:59:55 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a8.stj.sover.net [209.198.94.8] 209.198.94.8 Tue, 2 Jan 2001 23:59:55 -0500 (EST) Date: Wed, 3 Jan 2001 00:04:46 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Russ Ingram cc: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition 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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 2 Jan 2001, Russ Ingram wrote: > This is not in direct reference to the Root XFS partition thread, > but... > > Has anyone got a system running with all XFS filesystems (i.e. /boot / > /usr ...) and if so is there a HOWTO on how it was done. If there is > no HOWTO could someone possibly post an outline of the steps. I would > then be happy to write up a HOWTO for someone to post to the > http://oss.sgi.com/projects/xfs site (or wherever would be most > apropriate). I would like to have such a doc for myself and can only > imagine how much easier it will make it for others who would like to > create a similar system. > > Thanx, > Russ > > Russ Ingram > Gargoyle Computer Consulting > (307)760-1317 > www.gargoylecc.com > I have done such a thing. It's really not harder than moving to any other FS. I messd up by making XFS a module, so when it came time to mount /, it puked. it was a dumb mistake on my part, but I digress... Here is the basic outline: 1: compile in XFS support. you may be able to do less, but I have these XFS related options: <*> Page Buffer support (EXPERIMENTAL) (required for XFS) <*> SGI XFS filesystem support (EXPERIMENTAL) [ ] Enable XFS DMAPI (incomplete) [*] Enable XFS DEBUG mode (optional) [*] Enable XFS Vnode Tracing (optional) I believe all you *need* is Page Buffer and XFS support. someone correct me...the key is to buld them _in_ the kernel, not modules, if you intend on mounting / as xfs 2: compile the XFS userspace tools 3: make sure it all works on a spare partition 4: copy all your junk around and make the filesystems. or backup to tape and restore onto XFS partitions. or whatever you want. I have the space so I prefer playing 'musical partitions' with `cp -av` 5: I have a ext2 /boot, the rest is all XFS. note on the FAQ page it says you can use a XFS /boot now, I have not tried that yet. 6: edit /etc/fstab to mount things 'xfs' where you need too. 7: run lilo 8: reboot That's all there is. it's not complicated, just a little painstaking and time consuming ("musical partitions" is responsible for that :) Another thing to think about is if you have to have ext2 mounted, as I have /boot, you can mount it as ro (readonly) and don't fsck on reboot. then you are safe using ext2 on partitons that you only need RO access to. like maybe your MP3 collection. /dev/hda1 /boot ext2 defaults,ro 0 0 does it for me. if you have to re-mount do this: mount /boot -o rw,remount that remounts the partition with rw access. Just a couple tips that might help along the way, hope it helps :) To everyone doing development on XFS: keep up the good work, things work *great* (I'm already on your 2.4pre :) RegEx From owner-linux-xfs@oss.sgi.com Tue Jan 2 21:14:28 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 21:14:18 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4726 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 21:13:54 -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 VAA02617 for ; Tue, 2 Jan 2001 21:22:30 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15805 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 Jan 2001 16:12:36 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA90261 for ; Wed, 3 Jan 2001 16:12:35 +1100 (EST) Message-Id: <200101030512.QAA90261@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com X-URL: http://zoic.org/dxm Subject: full XFS system (XFS /boot & lilo) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 16:12:35 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Can someone clarify for me whether XFS works ok on a FULL xfs system now? ie does lilo work with an XFS /boot now? ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jan 2 21:53:50 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 21:53:39 -0800 Received: from garnet.sover.net ([209.198.87.53]:17884 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 21:53:11 -0800 Received: from [192.168.1.3] (pm1a8.stj.sover.net [209.198.94.8]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id AAA14065; Wed, 3 Jan 2001 00:53:06 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a8.stj.sover.net [209.198.94.8] 209.198.94.8 Wed, 3 Jan 2001 00:53:06 -0500 (EST) Date: Wed, 3 Jan 2001 00:58:08 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: full XFS system (XFS /boot & lilo) In-Reply-To: <200101030512.QAA90261@clouds.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 3 Jan 2001, Daniel Moore wrote: > > Can someone clarify for me whether XFS works ok on a FULL xfs > system now? ie does lilo work with an XFS /boot now? > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- > Indeed it does work with lilo and stuff. after seeing this e-mail, I decided to move my /boot to xfs and try it. I just did, and it works great. I am using the 2.4pre kernel and I think...2.4test11 user-space tools...any reason I shouldn't move on up? I was worried if stuff bugged out, I wouldn't be able to move back to an earlier kernel, because the newer userspace tools would create compatibility issues. I ran into this with Reiser...any thoughts? RegEx From owner-linux-xfs@oss.sgi.com Tue Jan 2 21:55:59 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 21:55:49 -0800 Received: from hermes.mixx.net ([212.84.196.2]:33037 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 2 Jan 2001 21:55:36 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B6C3EF80E for ; Wed, 3 Jan 2001 06:55:33 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 711C02CA6F; Wed, 3 Jan 2001 06:55:33 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: full XFS system (XFS /boot & lilo) Date: 3 Jan 2001 05:55:33 GMT Organization: innominate AG, Berlin, Germany Lines: 16 Distribution: local Message-ID: References: <200101030512.QAA90261@clouds.melbourne.sgi.com> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 978501333 17624 10.0.0.31 (3 Jan 2001 05:55:33 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > Can someone clarify for me whether XFS works ok on a FULL xfs > system now? ie does lilo work with an XFS /boot now? steve lord once said that he has it running fine after some initial problems and thats why i added it to the FAQ - never tested it myself (i think ext2 /boot is no problem and so far much safer) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 21:59:00 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 21:58:49 -0800 Received: from hermes.mixx.net ([212.84.196.2]:36365 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Tue, 2 Jan 2001 21:58:40 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 32647F80E for ; Wed, 3 Jan 2001 06:58:39 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id E03242CA6F; Wed, 3 Jan 2001 06:58:38 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: Root XFS partition Date: 3 Jan 2001 05:58:38 GMT Organization: innominate AG, Berlin, Germany Lines: 25 Distribution: local Message-ID: References: <3A4EC96C.2FA6DD32@thebarn.com> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 978501518 17624 10.0.0.31 (3 Jan 2001 05:58:38 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russ Ingram wrote: > This is not in direct reference to the Root XFS partition thread, > but... > Has anyone got a system running with all XFS filesystems (i.e. /boot / > /usr ...) and if so is there a HOWTO on how it was done. If there is > no HOWTO could someone possibly post an outline of the steps. I would > then be happy to write up a HOWTO for someone to post to the > http://oss.sgi.com/projects/xfs site (or wherever would be most > apropriate). I would like to have such a doc for myself and can only > imagine how much easier it will make it for others who would like to > create a similar system. btw. i have made a little initrd ramdisk to make the transition to XFS a bit easier (i hope :-) ... you may find it at http://innominate.org/~graichen/projects/miniroot/0.6/ t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 22:04:00 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 22:03:50 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:57400 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 22:03:41 -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 WAA17906 for ; Tue, 2 Jan 2001 22:02:48 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16057; Wed, 3 Jan 2001 17:02:22 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA09688; Wed, 3 Jan 2001 17:02:21 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101031702.ZM9781@wobbly.melbourne.sgi.com> Date: Wed, 3 Jan 2001 17:02:20 -0400 In-Reply-To: Jason Walker "Re: full XFS system (XFS /boot & lilo)" (Jan 3, 12:58am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Jason Walker , Daniel Moore Subject: Re: full XFS system (XFS /boot & lilo) Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi, On Jan 3, 12:58am, Jason Walker wrote: > Subject: Re: full XFS system (XFS /boot & lilo) > > ... > Indeed it does work with lilo and stuff. after seeing this > e-mail, I decided to move my /boot to xfs and try it. I just > did, and it works great. I am using the 2.4pre kernel and I > think...2.4test11 user-space tools...any reason I shouldn't > move on up? I was worried if stuff bugged out, I wouldn't be > able to move back to an earlier kernel, because the newer > userspace tools would create compatibility issues. I ran into > this with Reiser...any thoughts? > the only recent tools compatability issue would be moving from the beta tree (test5) to a development kernel (where the XFS log format changed so as to be more IRIX-compatible). moving from test11 to the prerelease kernel has no issues (in fact the tools are pretty much exactly the same). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 2 22:05:50 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 22:05:30 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:2564 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 22:05:26 -0800 Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0365Ne17926; Wed, 3 Jan 2001 00:05:23 -0600 (CST) Message-ID: <3A52C11D.A586625F@thebarn.com> Date: Wed, 03 Jan 2001 00:05:18 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Moore CC: linux-xfs@oss.sgi.com Subject: Re: full XFS system (XFS /boot & lilo) References: <200101030512.QAA90261@clouds.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > Can someone clarify for me whether XFS works ok on a FULL xfs > system now? ie does lilo work with an XFS /boot now? Steve checked the lilo fix in on Sep 20th. http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c?rev=1.69&content-type=text/x-cvsweb-markup > > > ----------------------------------------------------- > Daniel Moore dxm@sgi.com > R&D Software Engineer Phone: +61-3-98348209 > SGI Performance Tools Group Fax: +61-3-98132378 > ----------------------------------------------------- -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 22:15:20 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 22:15:00 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:5380 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 22:14:57 -0800 Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f036Ese18062; Wed, 3 Jan 2001 00:14:54 -0600 (CST) Message-ID: <3A52C359.D2BE21DA@thebarn.com> Date: Wed, 03 Jan 2001 00:14:49 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: TAKE - References: <6850.978487013@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Keith Owens wrote: > On Tue, 02 Jan 2001 19:44:51 -0600, > Russell Cattelan wrote: > >It's much easier to install a modified mkinitrd than more fiddling with anaconda. > > If you go that route, adding this line at the start is cleaner > > basicmodules="-pagebuf -xfs_support -xfs" Yes that does work better... Will change. > > > and remove the comments on > > # echo "No module $modName found for kernel $kernel" >&2 > # exit 1 > > Minimal maintainence in the future. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 22:35:50 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 22:35:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:54335 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 22:35:03 -0800 Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA20721 for ; Tue, 2 Jan 2001 22:34:10 -0800 (PST) mail_from (kenmcd@melbourne.sgi.com) Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id RAA73048; Wed, 3 Jan 2001 17:33:43 +1100 (AEDT) X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs Date: Wed, 3 Jan 2001 17:33:43 +1100 From: Ken McDonell Reply-To: kenmcd@sgi.com To: Jason Walker cc: linux-xfs@oss.sgi.com Subject: Re: full XFS system (XFS /boot & lilo) 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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 3 Jan 2001, Jason Walker wrote: > ... > I am using the 2.4pre kernel and I think...2.4test11 user-space > tools...any reason I shouldn't move on up? I was worried if stuff > bugged out, I wouldn't be able to move back to an earlier kernel, > because the newer userspace tools would create compatibility issues. I > ran into this with Reiser...any thoughts? In addition to Nathan's encouraging words, XFS should be much less volatile than a newly developed FS in this respect ... we are locked into the IRIX XFS MIPS on-disk format, and that is the most likely point of dependence between kernel version and user tools. This "lock" in is for disk migration between IRIX and Linux, and for the clustered CXFS product where both IRIX and Linux (and other assorted systems) will have direct, concurrent access to the filesystem on disk, so there is no room for making the on-disk formats different. Also the IRIX XFS MIPS on-disk format is not going to change due to the size of the installed base and our compatibility commitments to IRIX customers. And the Open Source format _is_ the IRIX MIPS format. From owner-linux-xfs@oss.sgi.com Tue Jan 2 22:45:20 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 22:45:00 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46200 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 22:44:59 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA05891 for ; Tue, 2 Jan 2001 22:53:15 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA32406; Wed, 3 Jan 2001 17:43:29 +1100 Date: Wed, 3 Jan 2001 17:43:29 +1100 From: Keith Owens Message-Id: <200101030643.RAA32406@sherman.melbourne.sgi.com> Subject: TAKE - 2.4.0-XFS-prerelease depmod/kdb tweaks To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 2 22:42:00 PST 2001 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:81488a linux/Makefile - 1.78 - Remove depmod_opts -r for make modules_install to /lib/modules. man depmod, -r is not suitable for a production system. linux/arch/i386/kdb/kdba_io.c - 1.10 - Correct keyboard delay calculation. loops_per_sec/50000 => loops_per_jiffy/(50000/HZ) From owner-linux-xfs@oss.sgi.com Tue Jan 2 23:03:51 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 23:03:41 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:9732 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 23:03:17 -0800 Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0373De18364; Wed, 3 Jan 2001 01:03:13 -0600 (CST) Message-ID: <3A52CEAB.765C5423@thebarn.com> Date: Wed, 03 Jan 2001 01:03:07 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker CC: Russ Ingram , linux-xfs@oss.sgi.com Subject: Re: Root XFS partition References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: > On Tue, 2 Jan 2001, Russ Ingram wrote: > > > This is not in direct reference to the Root XFS partition thread, > > but... > > > > Has anyone got a system running with all XFS filesystems (i.e. /boot / > > /usr ...) and if so is there a HOWTO on how it was done. If there is > > no HOWTO could someone possibly post an outline of the steps. I would > > then be happy to write up a HOWTO for someone to post to the > > http://oss.sgi.com/projects/xfs site (or wherever would be most > > apropriate). I would like to have such a doc for myself and can only > > imagine how much easier it will make it for others who would like to > > create a similar system. > > > > Thanx, > > Russ > > > > Russ Ingram > > Gargoyle Computer Consulting > > (307)760-1317 > > www.gargoylecc.com > > > > I have done such a thing. It's really not harder than moving to any other FS. I messd up by making XFS a module, so when it came time to mount /, it puked. it was a dumb mistake on my part, but I digress... Actually running xfs as a module isn't very hard. in the directory cmd/xfs/misc there is a modified mkinitrd the will always generate a ram disk with pagebuf xfs_support and xfs. Once that is done just add the initrd line in lilo.conf AND append = "ramdisk_size=25000" The default size is 4096 which isn't nearly large enough to hold xfs. This is from my laptop. punch[12:57am]-=>mount /dev/ide/host0/bus0/target0/lun0/part8 on / type xfs (rw,noatime) none on /proc type proc (rw) /dev/ide/host0/bus0/target0/lun0/part6 on /boot type ext2 (rw,noatime) none on /dev/pts type devpts (rw,mode=0620) /dev/ide/host0/bus0/target0/lun0/part1 on /mnt/windows type vfat (rw,nosuid,nodev,umask=0) /dev/ide/host0/bus0/target0/lun0/part9 on /blam type xfs (rw) punch[12:57am]-=>lsmod Module Size Used by autofs 13180 1 (autoclean) usb-uhci 24918 0 (unused) usbcore 35339 0 [usb-uhci] 3c59x 25149 1 (autoclean) maestro 29757 0 (unused) soundcore 6085 2 [maestro] vfat 13075 1 (autoclean) fat 37733 0 (autoclean) [vfat] xfs 447888 2 xfs_support 13954 0 [xfs] pagebuf 39935 2 [xfs] image=/boot/vmlinuz-2.4.0-XFS-test13-pre4 label=t13p4 root=/dev/hda8 initrd=/boot/initrd-2.4.0-XFS-test13p4.img append="ramdisk_size=25000" read-only Note we are very very close to having modified RH 7.0 installer that will be capable of doing an install straight to XFS partions. If all goes well I may be able to put a preliminary iso image on the ftp site tomorrow... thursday at the latest. > > Here is the basic outline: > > 1: compile in XFS support. you may be able to do less, but I have these XFS related options: > <*> Page Buffer support (EXPERIMENTAL) (required for XFS) > <*> SGI XFS filesystem support (EXPERIMENTAL) > [ ] Enable XFS DMAPI (incomplete) > [*] Enable XFS DEBUG mode (optional) > [*] Enable XFS Vnode Tracing (optional) > > I believe all you *need* is Page Buffer and XFS support. someone correct me...the key is to buld them _in_ the kernel, not modules, if you intend on mounting / as xfs > 2: compile the XFS userspace tools > 3: make sure it all works on a spare partition > 4: copy all your junk around and make the filesystems. or backup to tape and restore onto XFS partitions. or whatever you want. I have the space so I prefer playing 'musical partitions' with `cp -av` > 5: I have a ext2 /boot, the rest is all XFS. note on the FAQ page it says you can use a XFS /boot now, I have not tried that yet. > 6: edit /etc/fstab to mount things 'xfs' where you need too. > 7: run lilo > 8: reboot > > That's all there is. it's not complicated, just a little painstaking and time consuming ("musical partitions" is responsible for that :) Another thing to think about is if you have to have ext2 mounted, as I have /boot, you can mount it as ro (readonly) and don't fsck on reboot. then you are safe using ext2 on partitons that you only need RO access to. like maybe your MP3 collection. > > /dev/hda1 /boot ext2 defaults,ro 0 0 > > does it for me. if you have to re-mount do this: > > mount /boot -o rw,remount > > that remounts the partition with rw access. Just a couple tips that might help along the way, hope it helps :) > To everyone doing development on XFS: keep up the good work, things work *great* (I'm already on your 2.4pre :) > > RegEx > > -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 2 23:13:21 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 23:13:01 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34681 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 23:12:56 -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 XAA02647 for ; Tue, 2 Jan 2001 23:21:34 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id BAA321144 for ; Wed, 3 Jan 2001 01:11:40 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id BAA74983 for ; Wed, 3 Jan 2001 01:11:40 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f037Be701299 for linux-xfs@oss.sgi.com; Wed, 3 Jan 2001 01:11:40 -0600 Date: Wed, 3 Jan 2001 01:11:40 -0600 From: Russell Cattelan Message-Id: <200101030711.f037Be701299@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 2 23:11:27 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81492a cmd/xfs/misc/mkinitrd.xfs - 1.4 - Use better method of listing modules. From owner-linux-xfs@oss.sgi.com Tue Jan 2 23:35:11 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 23:35:02 -0800 Received: from edge.coltex.nl ([194.151.97.115]:64517 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 23:34:58 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id f037YmZ09428; Wed, 3 Jan 2001 08:34:48 +0100 Message-Id: <4.3.2.7.2.20010103082923.037e5d90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Jan 2001 08:32:35 +0100 To: Tom Duffy From: Seth Mos Subject: Re: CD recording under latest CVS 2.4.0-XFS-test12 Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 10:11 2-1-2001 -0800, you wrote: >have you tried: > >modprobe sg > >and then cdrecord -scanbus? > >-tduffy It used to work in the same config without sg. Everything after test5 broke. And 2.2 kernels always worked. I wanne check if it's the same bug as reported on lkml. Oh, if I do use sg it it still doesn't work. >On Wed, 27 Dec 2000, Seth Mos wrote: > > > Hi, > > > > Has anyone succeeded in burning CDR's under the latest CVS? > > Iam trying to figure out if this is also happened to ther people on this > > list. If this is a XFS kernel only problem I don't need make a fool of > > myself elsewhere ;-) > > > > I know it broke around test8 anyways and under XFS-test8 (according > > to the linux24 ToDo list http://linux24.sourceforge.net) > > > > Someone reported it fixed after that, but it is still broken over here. > > > > Following Specs that _work_ under XFS-test5 > > > > All scsi > > Diamond Fireport 40 (sym53c8xx) > > Philips CDD2600 (2x speed writer) > > Plextor 32x cdrom > > > > /proc/scsi/sym53c8xx/0 lists the adapter > > /proc/scsi/scsi lists both devices > > > > cd's are mountable in both drives. > > however cdrecord 1.9 doesn't find the writer with 'cdrecord -scanbus' > > > > cdrecord -scanbus -debug reports FFFFFFFF for every cookie on bus #0 - #15 > > > > Kind regards > > Seth > > -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Wed Jan 3 11:18:57 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 11:18:38 -0800 Received: from 209-161-7-106.gargoylecc.com ([209.161.7.106]:4225 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 11:18:32 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [209.161.7.106]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id MAA15594 for ; Wed, 3 Jan 2001 12:18:59 -0700 Date: Wed, 3 Jan 2001 12:18:59 -0700 (MST) From: Russel Ingram To: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition In-Reply-To: <3A52CEAB.765C5423@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok, a preliminary version of the HOWTO is done. The actual filesystem migration is still just a quote from Jason's message but will have more detail probably by Friday. Its at http://www.gargoylecc.com/Linux+XFS-HOWTO.txt and http://math.uwyo.edu/~ringram/Linux+XFS-HOWTO.txt Please take a look and let me know what you think (inaccuracies, improvements, etc) so far. Thanx, Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Wed Jan 3 11:36:27 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 11:36:08 -0800 Received: from [134.6.25.134] ([134.6.25.134]:20490 "EHLO mke.net") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 11:36:03 -0800 Received: (from jd@localhost) by mke.net (8.11.1/8.9.3) id f03BcaZ21215 for linux-xfs@oss.sgi.com; Wed, 3 Jan 2001 03:38:36 -0800 Date: Wed, 3 Jan 2001 03:38:36 -0800 From: "Joseph I. Davida" Message-Id: <200101031138.f03BcaZ21215@mke.net> To: linux-xfs@oss.sgi.com Subject: Re: Building latest Beta Failure Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > > On Wed, Dec 20, 2000 at 02:42:47PM +0000, Joseph I. Davida wrote: > > I had enabled dmapi option during configuration. > > If this feature is not ready, perhaps the config > > should grey it out completely? > > Or the user should use -d when doing a CVS update to grab new directories ? > > -Andi Well, the manpage says -d option is for setting the root directory: -d CVS_root_directory Use CVS_root_directory as the root directory path­ name of the master source repository. Overrides the setting of the CVSROOT environment variable. This value should be specified as an absolute path­ name. Or for creating a new directory in your version of the tree (assuming you KNOW that the source cvs tree has the new directgory name) and cvs update -d new_dir will bring in new_dir. But this requires that you know the new_dir name on the source repository in order to get it's contents. Catch 22? From owner-linux-xfs@oss.sgi.com Wed Jan 3 12:07:47 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 12:07:37 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:41517 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 12:07:13 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.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 MAA09830 for ; Wed, 3 Jan 2001 12:07:11 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA330681; Wed, 3 Jan 2001 14:05:54 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA31723; Wed, 3 Jan 2001 14:05:54 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id f03K5sG03994; Wed, 3 Jan 2001 14:05:54 -0600 Message-ID: <3A538621.C5F1C107@thebarn.com> Date: Wed, 03 Jan 2001 14:05:53 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: "Joseph I. Davida" CC: linux-xfs@oss.sgi.com Subject: Re: Building latest Beta Failure References: <200101031138.f03BcaZ21215@mke.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Joseph I. Davida" wrote: > Andi Kleen wrote: > > > > On Wed, Dec 20, 2000 at 02:42:47PM +0000, Joseph I. Davida wrote: > > > I had enabled dmapi option during configuration. > > > If this feature is not ready, perhaps the config > > > should grey it out completely? > > > > Or the user should use -d when doing a CVS update to grab new directories ? > > > > -Andi cvs has two -d options cvs -d cmd specifies the CVSROOT dir cvs -d update -d is a different flag the tells cvs up pull out any new directories. > > Well, the manpage says -d option is for setting the root directory: > > -d CVS_root_directory > Use CVS_root_directory as the root directory path­ > name of the master source repository. Overrides > the setting of the CVSROOT environment variable. > This value should be specified as an absolute path­ > name. > > Or for creating a new directory in your version of the > tree (assuming you KNOW that the source cvs tree has the > new directgory name) and cvs update -d new_dir will bring > in new_dir. But this requires that you know the new_dir > name on the source repository in order to get it's > contents. Catch 22? -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Jan 3 16:24:30 2001 Received: by oss.sgi.com id ; Wed, 3 Jan 2001 16:24:10 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:48150 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 3 Jan 2001 16:23:59 -0800 Received: from trantor.americas.sgi.com (128-162-211-23.americas.sgi.com [128.162.211.23]) 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 QAA04782 for ; Wed, 3 Jan 2001 16:23:57 -0800 (PST) mail_from (mann@trantor.americas.sgi.com) Received: (from mann@localhost) by trantor.americas.sgi.com (8.11.0/8.11.0) id f040RKb01747 for linux-xfs@oss.sgi.com; Wed, 3 Jan 2001 18:27:20 -0600 Date: Wed, 3 Jan 2001 18:27:20 -0600 From: Mark Nordstrand Message-Id: <200101040027.f040RKb01747@trantor.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Jan 3 16:23:09 PST 2001 Workarea: trantor.americas.sgi.com:/usr/home/man/work2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81568a linux/fs/xfs/xfs_error.c - 1.29 linux/fs/xfs/xfs_error.h - 1.19 linux/include/linux/xfs_fs.h - 1.19 linux/fs/xfs/linux/xfs_ioctl.c - 1.26 cmd/xfs/stress/src/fsstress.c - 1.7 cmd/xfs/include/xfs_fs.h - 1.8 - Moved error injection from SYSSGI to an ioctl(). From owner-linux-xfs@oss.sgi.com Thu Jan 4 13:57:15 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 13:56:56 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:1298 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 13:56:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA12990 for ; Thu, 4 Jan 2001 13:55:39 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA59017 for linux-xfs@oss.sgi.com; Fri, 5 Jan 2001 08:55:10 +1100 (EST) Date: Fri, 5 Jan 2001 08:55:10 +1100 (EST) From: Nathan Scott Message-Id: <200101042155.IAA59017@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing fixes a silly bug in the base quota tools package. On Jan 4, 2:40pm, Illo de' Illis wrote: > Subject: quota package and wishlist #67556 > ... a problem which makes the package unusable on big endian > architectures (getopt() returns int(-1) and not char(-1)). Modid: 2.4.x-xfs:slinx:81614a Date: Thu Jan 4 13:51:47 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/quota/quota.c - 1.4 cmd/quota/quotaon.c - 1.6 cmd/quota/setquota.c - 1.5 - fix getopt return value. From owner-linux-xfs@oss.sgi.com Thu Jan 4 14:44:16 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 14:43:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:48452 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 14:43:25 -0800 Received: from eric2.austin.sgi.com ([169.238.86.147]) 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 OAA00602 for ; Thu, 4 Jan 2001 14:43:16 -0800 (PST) mail_from (root@eric2.austin.sgi.com) Received: (from root@localhost) by eric2.austin.sgi.com (8.11.0/8.11.0) id f04Mgh826787 for linux-xfs@oss.sgi.com; Thu, 4 Jan 2001 16:42:43 -0600 Date: Thu, 4 Jan 2001 16:42:43 -0600 From: root Message-Id: <200101042242.f04Mgh826787@eric2.austin.sgi.com> Subject: TAKE - fs/Config.in tweak To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Thu Jan 4 14:41:36 PST 2001 Workarea: eric2.austin.sgi.com:/home/eric/xfs/workarea-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81623a linux/fs/Config.in - 1.48 - Clarified pagebuf <-> xfs relationship for user From owner-linux-xfs@oss.sgi.com Thu Jan 4 17:59:37 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 17:59:27 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:41592 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 17:59:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA24866 for ; Thu, 4 Jan 2001 17:58:26 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA33070 for linux-xfs@oss.sgi.com; Fri, 5 Jan 2001 12:57:57 +1100 (EST) Date: Fri, 5 Jan 2001 12:57:57 +1100 (EST) From: Nathan Scott Message-Id: <200101050157.MAA33070@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:81641a Date: Thu Jan 4 17:57:27 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/xfs_linux.h - 1.38 - merge in last couple of pseudo-inc headers (except acl). linux/fs/xfs/xfs.h - 1.12 - remove unused headers. From owner-linux-xfs@oss.sgi.com Thu Jan 4 18:20:37 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 18:20:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:39941 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 18:20:20 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA28191 for ; Thu, 4 Jan 2001 18:19:28 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f052HqS06586; Thu, 4 Jan 2001 20:17:52 -0600 Message-ID: <3A552ED0.6A4D1051@thebarn.com> Date: Thu, 04 Jan 2001 20:17:52 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: And oh, btw.. (fwd) References: <10101051251.ZM14702@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Nathan Scott wrote: > these folk will want to know too, Keith... > Ok one more round of merging coming up... give me a day or so. The modified RH installer is on its last round of debugging. I have successfully installed RH7.0 onto a system running only XFS. And had it boot up afterwards. I should have the first iso image for download a bit later tonight. Note we are using the latest anaconda install (7.1...blah blah blah) which does have some bugs, I will try to document any we come across but be warned there will be hiccups. > > > From: Keith Owens > To: ptg@melbourne.sgi.com > Subject: And oh, btw.. (fwd) > Date: Fri, 05 Jan 2001 12:48:27 +1100 > > I was beginning to think it would never occur ... > > ------- Forwarded Message > > Return-Path: > Date: Thu, 4 Jan 2001 16:01:22 -0800 (PST) > From: Linus Torvalds > To: Kernel Mailing List > Subject: And oh, btw.. > Message-ID: > > In a move unanimously hailed by the trade press and industry analysts as > being a sure sign of incipient braindamage, Linus Torvalds (also known as > the "father of Linux" or, more commonly, as "mush-for-brains") decided > that enough is enough, and that things don't get better from having the > same people test it over and over again. In short, 2.4.0 is out there. > > Anxiously awaited for the last too many months, 2.4.0 brings to the table > many improvements, none of which come to mind to the exhausted release > manager right now. "It's better", was the only printable quote. Pressed > for details, Linus bared his teeth and hissed at reporters, most of which > suddenly remembered that they'd rather cover "Home and Gardening" than the > IT industry anyway. > > Anyway, have fun. And don't bother reporting any bugs for the next few > days. I won't care anyway. > > Linus > > - ----- > Changes since the prerelease: > > David Mosberger: > - ia64 update > > NIIBE Yutaka: > - SuperH update > > Karsten Keil: > - re-do ISDN certification checksums > > Tim Waugh: > - VIA DMA=255 bug fix > - IEEE 1284 config message > - IEEE 1284 probe fix > - missing printk argument > - ppa driver reconnect timeout tweak > > Matthew Dharm: > - USB hotplug fix - specify exactly which fields to match on > > Rik Faith: > - drm driver synch with XFree86-4.0.2 > - oops: we synched a bit too far. Backsync to the _real_ 4.0.2 level. > > Geert Uytterhoeven: > - m68k updates > - Amiga resource management updates > - m68k loops_per_jiffy updates > - m68k keyboard delay/repeat > - m68k SCSI updates > - m68k exported symbols update > - m68k Lance updates > - fbdev config fixes > - Amiga Ethernet updates > - Amiga builtin serial updates > - m68k config updates > - m68k __ashldi3 > - Amiga Y2K fixes (a bit late, wouldn't you say?) > - Misc m68k updates > - fbdev init order fix > - Mac/m68k IDE updates > - m68k asm constraint fixes > > Marc ZYNGIER: > - SMP lockup with IrDA > > David Huggins-Daines: > - remove extra "remove_wait_queue()" in drivers/sound/cs46xx.c. It > would lock up badly on nonblocking reads. > > Matti Aarnio: > - teach tulip driver about media types 5 and 6 > - fix ATM LANE driver linkage issues > - fix DECNET driver unload time cleanup > - fix pointer comparison type warning > - get rid of excessive '##' token pasting that newer gcc's warn about > > Keith Owens: > - fix drm Makefile to not use the same objects built-in and in a module > - update modutils version numbers to match 2.4.x kernel > > Russell Kroll: > - fix radio card drivers that got the request_region sense inverted > > Rich Baum: > - Remove compile warnings with newer gcc versions for lables with no > expression at the end of a compound block > > Andreas Franck: > - Make the x86 semaphore implementation compile properly with current > gcc snapshots. Newer gcc's will release the memory allocated for a > data structure too early if only the pointer to that memory is passed > to an asm. > > Alan Cox: > - pcxx.c: make it compile ("mseconds" -> "msec") > - Documentation: fix typos/glitches > - CCISS bugfix > - riscom setup bugfix > - toshoboe and wavelan overlarge udelay > - clean/bugfixes amateur radio > - yam/mkiss build fix > - old tulip chips driver update > - sg driver unchecked scsi_allocate_request > - i810 audio fix > - RTC CMOS locking fixes > > David Miller: > - update sparc to "loops_per_jiffy" > - sparc32 uses ix86-like semaphores now > - missing flush_dcache_page in kiovec support layer > - netfilter: use "long" for values operated on using bitops > - more empty statement warning fixes > - LVM 32-bit compat ioctl checks > - Include param.h into Sparc64's delay.h to get HZ define > - Fix Zilog serial port speed setting checks > > Neil Brown: > - raid5 missing unlock on degraded array > - knfsd inode semaphore: get it early > > Johannes Erdfelt: > - USB oops on unplug fix for dc2xx and ov511 driver > > Mitch Davis: > - prettier printout of IDE registers if < 0x100 > > Richard Henderson: > - alpha "loops_per_jiffy" update > > Oliver Neukum: > - fix for SMP race in v4l open() > > Andreas Bombe: > - Makefile fix for ieee1394 > - IEEE 1394 up-to-date > > Kai Germaschewski: > - fix ISDN diversion services name-clash (and crash) > > Andre Hedrick: > - IDE chipset update, DVD-RAM update > > Rik van Riel: > - don't deactivate partially written pages in generic_file_write > > Michael Lang: > - ibmmca upgrade: docs and small bugs > > Marko Kreen: > - big udelay's in fb drivers. Fix. > > Me: > - drivers/net/rcpci45.c: make it compile ("rcpci_pci_table" -> > "rcpci45_pci_table") > - mark_buffer_dirty() only does a "balance_dirty()" if the > buffer was previously clean. > - mm sanity: never decrement page count past zero > - no synchronous bdflush wait > - mm VM scanning and exit race cleanup: mmlist_lock > > - - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ > > ------- End of Forwarded Message > > ---End of forwarded mail from Keith Owens > > -- > Nathan -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Thu Jan 4 18:35:28 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 18:35:19 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:48145 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 18:34:56 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id NAA27061; Fri, 5 Jan 2001 13:34:31 +1100 (EST) Message-ID: <3A5533AA.75C6090F@arts.usyd.edu.au> Date: Fri, 05 Jan 2001 13:38:34 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS-prerelease i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Russell Cattelan CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: And oh, btw.. (fwd) References: <10101051251.ZM14702@wobbly.melbourne.sgi.com> <3A552ED0.6A4D1051@thebarn.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9670AAD94DC5AE851177362B" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms9670AAD94DC5AE851177362B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russell Cattelan wrote: > > Nathan Scott wrote: > > > these folk will want to know too, Keith... > > > > Ok one more round of merging coming up... give me a day or > so. > > The modified RH installer is on its last round of debugging. > > I have successfully installed RH7.0 onto a system running > only XFS. And had it boot up afterwards. > > I should have the first iso image for download a bit later tonight. > > Note we are using the latest anaconda install (7.1...blah blah blah) > which does have some bugs, I will try to document any we come across > but be warned there will be hiccups. > Im interesting in getting hold of this - just got a new dell laptop here (Latitude C600) that is to run Linux. This machine will be used for network testing and be very mobile and probably powered up and down all the time. Having a root fs that doesnt need to be fsked when some one pulls the power on it at the wrong time would be nice :-) And I can also test xfs in an extreme environment before putting on our server. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms9670AAD94DC5AE851177362B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA1MDIzODM1WjAjBgkq hkiG9w0BCQQxFgQUb2c4SXqo4qnl7EvZuQI62Pute3wwOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYBg2/U+X3L1r16QkEvBNOWBH8tEYhjwFwELwk4yy3EWXKaI6v0FpH6QlDx7CT3sG+OEvTR3 n8k/ELmj8n+0oFvSGA+Qm+y+MjrDtNG1rUdawQvLRI9TH28nDGK7GuTVP7wQAQcXBkvDlu1G MnuYIxso/ffkSkV5l0HXqPW6ZelypQ== --------------ms9670AAD94DC5AE851177362B-- From owner-linux-xfs@oss.sgi.com Thu Jan 4 20:19:19 2001 Received: by oss.sgi.com id ; Thu, 4 Jan 2001 20:19:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:25139 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 4 Jan 2001 20:18:46 -0800 Received: from sydney.sydney.sgi.com ([134.14.48.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA08281; Thu, 4 Jan 2001 20:18:09 -0800 (PST) mail_from (kaos@ocs.com.au) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id PAA23996; Fri, 5 Jan 2001 15:16:51 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com, linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [Announce] kdb v1.7 is available for 2.4.0 Date: Fri, 05 Jan 2001 15:16:51 +1100 Message-ID: <17826.978668211@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb v1.7 against kernel 2.4.0. No significant changes since 2.4.0-test13 and 2.4.0-prerelease. Just fitting the patch to the new kernel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6VUqyi4UHNye0ZOoRAsT2AKDuZqYxy6c9yejqawPo4Z908iABVgCg80/x DKMCyxQvwl2fAHMKxm+2eec= =YofV -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Jan 5 09:19:53 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 09:19:43 -0800 Received: from mail.connex.com ([216.100.236.3]:17427 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 09:19:25 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 09:16:30 -0800 Message-ID: From: Scott Smyth To: "'linux-xfs@oss.sgi.com '" Cc: Dale Stephenson Subject: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM Date: Fri, 5 Jan 2001 09:16:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0773B.3D3652C0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0773B.3D3652C0 Content-Type: text/plain Hi; Now that LVM is in the SGI tree, we would like to find out if anybody is seeing similar issues around RAID 5 software support and the complaints of mount with XFS in the kernel and trying to mount LVM volumes: LVM 0.9 (obviously) 2.4.0-test13-pre3 and 2.4.0-prerelease First, there are two problems we seem to have with RAID 5 with LVM on top and XFS as the file system. The first is that the MMX optimization in xor.h fails and keeps the xor module from even loading properly (see attached patch to avoid this). Having gotten around that, we then have a problem with the rsync daemon. We get a kernel oops (we have not had time to use kdb on it yet but will) on the starting the raid, but you can still proceed and use it. However, it never resyncs nor makes any progress to resync according to /proc/mdstat. Then, at shutdown of the raidset (or attempted), the raid stop hangs. We will give more info as we debug, but it is 100% reproduceable. Second, with XFS in the kernel in order to use a root XFS system, mount (2.10m) complains that the major and/or minor numbers of the device are incorrect and mount will not work unless you force it. I believe this is just a detection issue of mount() with XFS in the kernel as it works when you force it. umount, however, complains no matter what even though it does unmount it. As we find more information or fixes, we will send them on to the list. If anyone sees similar issues, please let us know. thanks, Scott ------_=_NextPart_000_01C0773B.3D3652C0 Content-Type: application/octet-stream; name="raid5_piii_avoid_xor.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="raid5_piii_avoid_xor.patch" --- linux/include/asm-i386/xor.h.orig Thu Dec 28 15:37:10 2000=0A= +++ linux/include/asm-i386/xor.h Thu Dec 28 16:49:26 2000=0A= @@ -843,7 +843,7 @@=0A= do { \=0A= xor_speed(&xor_block_8regs); \=0A= xor_speed(&xor_block_32regs); \=0A= - if (cpu_has_xmm) \=0A= + if (0) \=0A= xor_speed(&xor_block_pIII_sse); \=0A= if (md_cpu_has_mmx()) { \=0A= xor_speed(&xor_block_pII_mmx); \=0A= @@ -854,5 +854,9 @@=0A= /* We force the use of the SSE xor block because it can write around = L2.=0A= We may also be able to load into the L1 only depending on how the = cpu=0A= deals with a load to a line that is being prefetched. */=0A= +/* Scott Smyth, Connex, 12/28/2000=0A= + * Avoiding SSE/Piii optimization now because it fails on NULL = dereference:=0A= + * cpu_has_xmm ? &xor_block_pIII_sse : FASTEST=0A= + */=0A= #define XOR_SELECT_TEMPLATE(FASTEST) \=0A= - (cpu_has_xmm ? &xor_block_pIII_sse : FASTEST)=0A= + (0 ? &xor_block_pIII_sse : FASTEST)=0A= ------_=_NextPart_000_01C0773B.3D3652C0-- From owner-linux-xfs@oss.sgi.com Fri Jan 5 10:11:03 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 10:10:44 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21097 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 10:10:33 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA04924 for ; Fri, 5 Jan 2001 10:19:04 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA39530; Fri, 5 Jan 2001 10:04:23 -0800 (PST) Message-ID: <3A560D3F.A8784FBF@sgi.com> Date: Fri, 05 Jan 2001 10:06:55 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Scott Smyth CC: "'linux-xfs@oss.sgi.com '" , Dale Stephenson , neilb@cse.unsw.edu.au Subject: Re: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Scott Smyth wrote: > > Hi; > > Now that LVM is in the SGI tree, we would like to > find out if anybody is seeing similar issues > around RAID 5 software support and the complaints > of mount with XFS in the kernel and trying to mount > LVM volumes: > > LVM 0.9 (obviously) > 2.4.0-test13-pre3 and 2.4.0-prerelease > > First, there are two problems we seem to have with > RAID 5 with LVM on top and XFS as the file system. > The first is that the MMX optimization in xor.h > fails and keeps the xor module from even loading > properly (see attached patch to avoid this). Having > gotten around that, we then have a problem with > the rsync daemon. We get a kernel oops (we have not > had time to use kdb on it yet but will) on the > starting the raid, but you can still proceed and > use it. However, it never resyncs nor makes any > progress to resync according to /proc/mdstat. Then, > at shutdown of the raidset (or attempted), the > raid stop hangs. We will give more info as we debug, > but it is 100% reproduceable. > [ ... ] Hi, We have seen similar issues both w.r.t the sse optimizations and w.r.t re-syncing. The sse issue surfaced when the raid code got re-worked to factor out some of the architecture/processor specific optimizations. I don't know if accessing the device while resyncing is intented to work. One workaround for the resync problem is to wait for the raid to finish resyncing; the status, as you noted, is reported in /proc/mdstat. In our test box, the processor is: ---------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 2 cpu MHz : 500.141 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 : 996.15 -------------------- I'll cc: Neil Brown who seems to be actively maintaining the RAID subsystem. thanks, -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jan 5 10:16:34 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 10:16:14 -0800 Received: from mail.connex.com ([216.100.236.3]:32521 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 10:15:56 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 10:13:02 -0800 Message-ID: From: Scott Smyth To: 'Rajagopal Ananthanarayanan ' , Scott Smyth Cc: "''linux-xfs@oss.sgi.com ' '" , Dale Stephenson , "'neilb@cse.unsw.edu.au '" Subject: RE: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM Date: Fri, 5 Jan 2001 10:12:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi; The problem is that the resync _never_ finishes. I mean never. Or are you saying you took the sse code for the MMX out of something besides the xor.h? With our one patch, we can get it started but the resync never goes forward. thanks, Scott -----Original Message----- From: Rajagopal Ananthanarayanan To: Scott Smyth Cc: 'linux-xfs@oss.sgi.com '; Dale Stephenson; neilb@cse.unsw.edu.au Sent: 1/5/01 10:06 AM Subject: Re: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM Scott Smyth wrote: > > Hi; > > Now that LVM is in the SGI tree, we would like to > find out if anybody is seeing similar issues > around RAID 5 software support and the complaints > of mount with XFS in the kernel and trying to mount > LVM volumes: > > LVM 0.9 (obviously) > 2.4.0-test13-pre3 and 2.4.0-prerelease > > First, there are two problems we seem to have with > RAID 5 with LVM on top and XFS as the file system. > The first is that the MMX optimization in xor.h > fails and keeps the xor module from even loading > properly (see attached patch to avoid this). Having > gotten around that, we then have a problem with > the rsync daemon. We get a kernel oops (we have not > had time to use kdb on it yet but will) on the > starting the raid, but you can still proceed and > use it. However, it never resyncs nor makes any > progress to resync according to /proc/mdstat. Then, > at shutdown of the raidset (or attempted), the > raid stop hangs. We will give more info as we debug, > but it is 100% reproduceable. > [ ... ] Hi, We have seen similar issues both w.r.t the sse optimizations and w.r.t re-syncing. The sse issue surfaced when the raid code got re-worked to factor out some of the architecture/processor specific optimizations. I don't know if accessing the device while resyncing is intented to work. One workaround for the resync problem is to wait for the raid to finish resyncing; the status, as you noted, is reported in /proc/mdstat. In our test box, the processor is: ---------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 2 cpu MHz : 500.141 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 : 996.15 -------------------- I'll cc: Neil Brown who seems to be actively maintaining the RAID subsystem. thanks, ------------------------------------------------------------------------ -- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. ------------------------------------------------------------------------ -- From owner-linux-xfs@oss.sgi.com Fri Jan 5 10:47:44 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 10:47:35 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:21053 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 10:47:20 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.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 KAA04695 for ; Fri, 5 Jan 2001 10:47:17 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA360214 for ; Fri, 5 Jan 2001 12:46:02 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA92973 for ; Fri, 5 Jan 2001 12:46:01 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f05Ik1G04803 for linux-xfs@oss.sgi.com; Fri, 5 Jan 2001 12:46:01 -0600 Date: Fri, 5 Jan 2001 12:46:01 -0600 From: Russell Cattelan Message-Id: <200101051846.f05Ik1G04803@gibble.americas.sgi.com> Subject: TAKE - No more waiting! The bit 2.4.0 release is here! To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Update to 2.4.0 Release Date: Fri Jan 5 10:42:30 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-R The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81664a linux/arch/ia64/sn/io/stubs.c - 1.1 linux/include/asm-ia64/sn/addrs.h - 1.1 linux/include/asm-ia64/sn/agent.h - 1.1 linux/include/asm-ia64/sn/alenlist.h - 1.1 linux/include/asm-ia64/sn/arc/hinv.h - 1.1 linux/include/asm-ia64/sn/arc/types.h - 1.1 linux/include/asm-ia64/sn/arch.h - 1.1 linux/include/asm-ia64/sn/cdl.h - 1.1 linux/include/asm-ia64/sn/clksupport.h - 1.1 linux/include/asm-ia64/sn/cmn_err.h - 1.1 linux/include/asm-ia64/sn/dmamap.h - 1.1 linux/include/asm-ia64/sn/driver.h - 1.1 linux/include/asm-ia64/sn/eeprom.h - 1.1 linux/include/asm-ia64/sn/gda.h - 1.1 linux/include/asm-ia64/sn/hack.h - 1.1 linux/include/asm-ia64/sn/hcl.h - 1.1 linux/include/asm-ia64/sn/hcl_util.h - 1.1 linux/include/asm-ia64/sn/hubspc.h - 1.1 linux/include/asm-ia64/sn/hwcntrs.h - 1.1 linux/include/asm-ia64/sn/intr.h - 1.1 linux/include/asm-ia64/sn/intr_public.h - 1.1 linux/include/asm-ia64/sn/invent.h - 1.1 linux/include/asm-ia64/sn/io.h - 1.1 linux/include/asm-ia64/sn/iobus.h - 1.1 linux/drivers/char/drm/r128_state.c - 1.1 linux/include/asm-ia64/sn/ioc3.h - 1.1 linux/include/asm-ia64/sn/ioerror.h - 1.1 linux/include/asm-ia64/sn/ioerror_handling.h - 1.1 linux/include/asm-ia64/sn/iograph.h - 1.1 linux/include/asm-ia64/sn/klconfig.h - 1.1 linux/drivers/char/drm/r128_cce.c - 1.1 linux/include/asm-ia64/sn/kldir.h - 1.1 linux/include/asm-ia64/sn/ksys/elsc.h - 1.1 linux/include/asm-ia64/sn/ksys/i2c.h - 1.1 linux/include/asm-ia64/sn/ksys/l1.h - 1.1 linux/include/asm-ia64/sn/labelcl.h - 1.1 linux/arch/ia64/kernel/iosapic.c - 1.1 linux/include/asm-ia64/sn/mem_refcnt.h - 1.1 linux/include/asm-sh/rtc.h - 1.1 linux/include/asm-ia64/sn/mmzone.h - 1.1 linux/include/asm-ia64/sn/mmzone_default.h - 1.1 linux/include/asm-ia64/sn/mmzone_sn1.h - 1.1 linux/include/asm-ia64/sn/module.h - 1.1 linux/include/asm-ia64/sn/nic.h - 1.1 linux/include/asm-ia64/sn/nodemask.h - 1.1 linux/include/asm-ia64/sn/xtalk/xwidget.h - 1.1 linux/include/asm-ia64/sn/xtalk/xtalkaddrs.h - 1.1 linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.1 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.1 linux/include/asm-ia64/sn/xtalk/xswitch.h - 1.1 linux/include/asm-ia64/sn/xtalk/xbow_info.h - 1.1 linux/include/asm-ia64/sn/xtalk/xbow.h - 1.1 linux/include/asm-ia64/sn/war.h - 1.1 linux/include/asm-ia64/sn/vector.h - 1.1 linux/include/asm-ia64/sn/types.h - 1.1 linux/include/asm-ia64/sn/systeminfo.h - 1.1 linux/include/asm-ia64/sn/synergy.h - 1.1 linux/include/asm-ia64/sn/sn_private.h - 1.1 linux/include/asm-ia64/sn/sn_fru.h - 1.1 linux/include/asm-ia64/sn/sn_cpuid.h - 1.1 linux/include/asm-ia64/sn/sn1/war.h - 1.1 linux/include/asm-ia64/sn/sn1/uart16550.h - 1.1 linux/include/asm-ia64/sn/sn1/sn1.h - 1.1 linux/include/asm-ia64/sn/sn1/slotnum.h - 1.1 linux/arch/ia64/lib/swiotlb.c - 1.1 linux/include/asm-ia64/sn/sn1/router.h - 1.1 linux/include/asm-ia64/sn/sn1/promlog.h - 1.1 linux/include/asm-ia64/sn/sn1/leds.h - 1.1 linux/include/asm-ia64/sn/sn1/kldir.h - 1.1 linux/include/asm-ia64/sn/sn1/ip27config.h - 1.1 linux/arch/ia64/sn/fprom/Makefile - 1.1 linux/arch/ia64/sn/fprom/README - 1.1 linux/arch/ia64/sn/fprom/fpmem.c - 1.1 linux/arch/ia64/sn/fprom/fpmem.h - 1.1 linux/arch/ia64/sn/fprom/fprom.lds - 1.1 linux/arch/ia64/sn/fprom/fpromasm.S - 1.1 linux/arch/ia64/sn/fprom/fw-emu.c - 1.1 linux/arch/ia64/sn/fprom/main.c - 1.1 linux/arch/ia64/sn/fprom/runsim - 1.1 linux/arch/ia64/sn/io/Makefile - 1.1 linux/arch/ia64/sn/io/alenlist.c - 1.1 linux/arch/ia64/sn/io/cdl.c - 1.1 linux/arch/ia64/sn/io/devsupport.c - 1.1 linux/arch/ia64/sn/io/eeprom.c - 1.1 linux/arch/ia64/sn/io/hcl.c - 1.1 linux/arch/ia64/sn/io/hcl_util.c - 1.1 linux/arch/ia64/sn/io/hubdev.c - 1.1 linux/arch/ia64/sn/io/hubspc.c - 1.1 linux/arch/ia64/sn/io/invent.c - 1.1 linux/arch/ia64/sn/io/io.c - 1.1 linux/arch/ia64/sn/io/ip37.c - 1.1 linux/arch/ia64/sn/io/klconflib.c - 1.1 linux/arch/ia64/sn/io/klgraph.c - 1.1 linux/arch/ia64/sn/io/klgraph_hack.c - 1.1 linux/arch/ia64/sn/io/l1.c - 1.1 linux/arch/ia64/sn/io/l1_command.c - 1.1 linux/arch/ia64/sn/io/labelcl.c - 1.1 linux/arch/ia64/sn/io/mem_refcnt.c - 1.1 linux/arch/ia64/sn/io/ml_SN_init.c - 1.1 linux/arch/ia64/sn/io/ml_SN_intr.c - 1.1 linux/arch/ia64/sn/io/ml_iograph.c - 1.1 linux/arch/ia64/sn/io/module.c - 1.1 linux/arch/ia64/sn/io/pci.c - 1.1 linux/arch/ia64/sn/io/pci_bus_cvlink.c - 1.1 linux/arch/ia64/sn/io/pci_dma.c - 1.1 linux/arch/ia64/sn/io/pcibr.c - 1.1 linux/arch/ia64/sn/io/pciio.c - 1.1 linux/arch/ia64/sn/io/sgi_if.c - 1.1 linux/arch/ia64/sn/io/sgi_io_init.c - 1.1 linux/arch/ia64/sn/io/sgi_io_sim.c - 1.1 linux/include/asm-ia64/sn/nodepda.h - 1.1 linux/arch/ia64/sn/io/xbow.c - 1.1 linux/arch/ia64/sn/io/xswitch.c - 1.1 linux/arch/ia64/sn/io/xtalk.c - 1.1 linux/include/asm-ia64/sn/sn1/hubxb_next.h - 1.1 linux/arch/ia64/sn/sn1/discontig.c - 1.1 linux/arch/ia64/sn/sn1/iomv.c - 1.1 linux/include/asm-ia64/sn/sn1/hubxb.h - 1.1 linux/arch/ia64/sn/sn1/llsc4.c - 1.1 linux/arch/ia64/sn/sn1/llsc4.h - 1.1 linux/arch/ia64/sn/sn1/mm.c - 1.1 linux/include/asm-ia64/sn/sn1/hubpi_next.h - 1.1 linux/arch/ia64/sn/sn1/smp.c - 1.1 linux/arch/ia64/sn/sn1/sn1_asm.S - 1.1 linux/arch/ia64/sn/sn1/synergy.c - 1.1 linux/arch/ia64/sn/tools/make_textsym - 1.1 linux/include/asm-ia64/sn/sn1/hubpi.h - 1.1 linux/include/asm-ia64/sn/sn1/hubni_next.h - 1.1 linux/include/asm-ia64/sn/sn1/hubni.h - 1.1 linux/include/asm-ia64/sn/sn1/hubmd_next.h - 1.1 linux/include/asm-ia64/sn/sn1/hubmd.h - 1.1 linux/include/asm-ia64/sn/sn1/hublb_next.h - 1.1 linux/include/asm-ia64/sn/sn1/hublb.h - 1.1 linux/include/asm-ia64/sn/sn1/hubio_next.h - 1.1 linux/include/asm-ia64/sn/sn1/hubio.h - 1.1 linux/include/asm-ia64/sn/sn1/hubdev.h - 1.1 linux/include/asm-ia64/sn/sn1/bedrock.h - 1.1 linux/include/asm-ia64/sn/sn1/arch.h - 1.1 linux/arch/m68k/lib/ashldi3.c - 1.1 linux/include/asm-ia64/sn/sn1/addrs.h - 1.1 linux/include/asm-ia64/sn/slotnum.h - 1.1 linux/include/asm-ia64/sn/sgi.h - 1.1 linux/arch/sh/kernel/rtc.c - 1.1 linux/include/asm-ia64/sn/router.h - 1.1 linux/include/asm-ia64/sn/prio.h - 1.1 linux/include/asm-ia64/sn/pio.h - 1.1 linux/include/asm-ia64/sn/pci/pciio_private.h - 1.1 linux/include/asm-ia64/sn/pci/pciio.h - 1.1 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.1 linux/include/asm-ia64/sn/pci/pcibr.h - 1.1 linux/include/asm-ia64/sn/pci/pci_defs.h - 1.1 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.1 linux/include/asm-ia64/sn/pci/bridge.h - 1.1 linux/net/sched/sch_api.c - 1.10 linux/net/packet/af_packet.c - 1.20 linux/net/irda/irqueue.c - 1.7 linux/net/irda/irias_object.c - 1.7 linux/net/ipv6/udp.c - 1.19 linux/net/ipv6/tcp_ipv6.c - 1.21 linux/net/ipv6/icmp.c - 1.9 linux/net/ipv6/addrconf.c - 1.13 linux/net/ipv4/udp.c - 1.21 linux/net/ipv4/tcp_timer.c - 1.16 linux/net/ipv4/tcp_ipv4.c - 1.31 linux/net/ipv4/arp.c - 1.15 linux/mm/vmscan.c - 1.43 linux/mm/page_alloc.c - 1.33 linux/mm/memory.c - 1.42 linux/mm/filemap.c - 1.62 linux/kernel/signal.c - 1.17 linux/kernel/sched.c - 1.30 linux/kernel/ksyms.c - 1.70 linux/kernel/fork.c - 1.27 linux/kernel/exit.c - 1.26 linux/init/main.c - 1.48 linux/include/net/sock.h - 1.21 linux/include/net/irda/irda.h - 1.11 linux/include/linux/sched.h - 1.35 linux/include/linux/scc.h - 1.4 linux/include/linux/mc146818rtc.h - 1.5 linux/include/linux/delay.h - 1.4 linux/include/linux/dcache.h - 1.14 linux/include/asm-sparc64/processor.h - 1.15 linux/include/asm-sparc64/delay.h - 1.6 linux/include/asm-sparc/semaphore.h - 1.5 linux/include/asm-sparc/semaphore-helper.h - 1.4 linux/include/asm-sparc/processor.h - 1.12 linux/include/asm-sparc/delay.h - 1.3 linux/include/asm-sparc/contregs.h - 1.4 linux/include/asm-sparc/atomic.h - 1.6 linux/include/asm-m68k/traps.h - 1.3 linux/include/asm-m68k/serial.h - 1.3 linux/include/asm-m68k/param.h - 1.6 linux/include/asm-m68k/io.h - 1.5 linux/include/asm-m68k/floppy.h - 1.3 linux/include/asm-m68k/delay.h - 1.3 linux/include/asm-i386/semaphore.h - 1.13 linux/include/asm-i386/floppy.h - 1.5 linux/include/asm-alpha/smp.h - 1.14 linux/include/asm-alpha/delay.h - 1.7 linux/fs/umsdos/mangle.c - 1.3 linux/fs/nfsd/nfsfh.c - 1.23 linux/fs/isofs/inode.c - 1.20 linux/fs/exec.c - 1.37 linux/fs/dcache.c - 1.20 linux/fs/buffer.c - 1.50 linux/drivers/video/retz3fb.c - 1.10 linux/drivers/video/fbmem.c - 1.33 linux/drivers/video/clgenfb.c - 1.16 linux/drivers/video/atyfb.c - 1.26 linux/drivers/video/Config.in - 1.24 linux/drivers/usb/usb.c - 1.44 linux/drivers/usb/hub.c - 1.32 linux/drivers/usb/audio.c - 1.28 linux/drivers/sound/sound_timer.c - 1.7 linux/drivers/sound/sequencer.c - 1.8 linux/drivers/sound/sb_ess.c - 1.10 linux/drivers/sound/mpu401.c - 1.10 linux/drivers/scsi/tmscsim.c - 1.10 linux/drivers/scsi/sym53c8xx.c - 1.20 linux/drivers/scsi/sg.c - 1.17 linux/drivers/scsi/ppa.h - 1.7 linux/drivers/scsi/ppa.c - 1.8 linux/drivers/scsi/mac_esp.c - 1.7 linux/drivers/scsi/mac_NCR5380.c - 1.4 linux/drivers/scsi/ibmmca.c - 1.11 linux/drivers/scsi/README.ibmmca - 1.5 linux/drivers/sbus/char/zs.c - 1.14 linux/drivers/net/rcpci45.c - 1.15 linux/drivers/net/ne.c - 1.13 linux/drivers/net/hydra.c - 1.11 linux/drivers/net/hamradio/scc.c - 1.13 linux/drivers/net/hamradio/pt.c - 1.8 linux/drivers/net/hamradio/pi2.c - 1.8 linux/drivers/net/hamradio/mkiss.c - 1.9 linux/drivers/net/hamradio/Makefile - 1.8 linux/drivers/net/hamradio/6pack.h - 1.5 linux/drivers/net/hamradio/6pack.c - 1.9 linux/drivers/net/ariadne2.c - 1.10 linux/drivers/net/acenic.c - 1.23 linux/drivers/net/Space.c - 1.28 linux/drivers/net/Makefile - 1.38 linux/drivers/net/Config.in - 1.34 linux/drivers/net/8390.h - 1.7 linux/drivers/net/8390.c - 1.18 linux/drivers/net/7990.h - 1.4 linux/drivers/net/7990.c - 1.4 linux/drivers/isdn/isdn_common.c - 1.19 linux/drivers/isdn/hisax/teles3c.c - 1.4 linux/drivers/isdn/Config.in - 1.14 linux/drivers/char/vt.c - 1.17 linux/drivers/char/rtc.c - 1.19 linux/drivers/char/riscom8.c - 1.8 linux/drivers/char/pcxx.c - 1.11 linux/drivers/char/nvram.c - 1.11 linux/drivers/char/mem.c - 1.31 linux/drivers/char/Makefile - 1.40 linux/drivers/block/ataflop.c - 1.12 linux/arch/sparc64/kernel/smp.c - 1.20 linux/arch/sparc64/kernel/setup.c - 1.15 linux/arch/sparc64/kernel/ioctl32.c - 1.28 linux/arch/sparc/mm/fault.c - 1.13 linux/arch/sparc/kernel/smp.c - 1.13 linux/arch/sparc/kernel/setup.c - 1.16 linux/arch/sparc/kernel/entry.S - 1.9 linux/arch/m68k/mm/fault.c - 1.8 linux/arch/m68k/lib/Makefile - 1.8 linux/arch/m68k/kernel/traps.c - 1.9 linux/arch/m68k/kernel/time.c - 1.4 linux/arch/m68k/kernel/setup.c - 1.11 linux/arch/m68k/kernel/m68k_ksyms.c - 1.10 linux/arch/m68k/kernel/m68k_defs.h - 1.4 linux/arch/m68k/config.in - 1.20 linux/arch/m68k/atari/debug.c - 1.6 linux/arch/m68k/amiga/config.c - 1.7 linux/arch/m68k/amiga/amisound.c - 1.7 linux/arch/m68k/Makefile - 1.6 linux/arch/i386/vmlinux.lds - 1.12 linux/arch/i386/kernel/traps.c - 1.33 linux/arch/i386/kernel/process.c - 1.30 linux/arch/alpha/kernel/smp.c - 1.20 linux/arch/alpha/kernel/setup.c - 1.17 linux/README - 1.9 linux/Makefile - 1.79 linux/Documentation/rtc.txt - 1.4 linux/Documentation/IO-mapping.txt - 1.5 linux/Documentation/Configure.help - 1.69 linux/Documentation/Changes - 1.30 linux/net/decnet/af_decnet.c - 1.19 linux/drivers/usb/printer.c - 1.32 linux/drivers/usb/acm.c - 1.35 linux/drivers/net/irda/toshoboe.c - 1.20 linux/drivers/isdn/hisax/md5sums.asc - 1.9 linux/drivers/parport/probe.c - 1.4 linux/drivers/parport/parport_pc.c - 1.29 linux/drivers/parport/ieee1284.c - 1.10 linux/drivers/net/mvme147.c - 1.5 linux/drivers/usb/uss720.c - 1.16 linux/drivers/scsi/sun3x_esp.c - 1.2 linux/net/atm/lec.c - 1.10 linux/net/atm/lane_mpoa_init.c - 1.4 linux/net/atm/common.c - 1.8 linux/net/atm/Makefile - 1.7 linux/arch/sparc/kernel/semaphore.c - 1.5 linux/arch/sh/mm/fault.c - 1.13 linux/arch/sh/lib/delay.c - 1.2 linux/arch/sh/kernel/time.c - 1.13 linux/arch/sh/kernel/sh_ksyms.c - 1.5 linux/arch/sh/kernel/setup.c - 1.11 linux/arch/sh/kernel/Makefile - 1.10 linux/arch/sh/config.in - 1.15 linux/include/asm-sh/uaccess.h - 1.8 linux/include/asm-sh/timex.h - 1.3 linux/include/asm-sh/siginfo.h - 1.4 linux/include/asm-sh/ptrace.h - 1.6 linux/include/asm-sh/processor.h - 1.11 linux/include/asm-sh/pgtable.h - 1.15 linux/include/asm-sh/param.h - 1.2 linux/include/asm-sh/mmu_context.h - 1.9 linux/include/asm-sh/delay.h - 1.7 linux/include/asm-sh/bugs.h - 1.6 linux/include/asm-m68k/movs.h - 1.3 linux/include/linux/udf_fs.h - 1.9 linux/drivers/char/drm/drm.h - 1.6 linux/drivers/char/drm/Makefile - 1.7 linux/include/linux/pci_ids.h - 1.31 linux/drivers/net/pcmcia/wavelan_cs.c - 1.7 linux/include/asm-sh/pgtable-2level.h - 1.4 linux/drivers/usb/dc2xx.c - 1.14 linux/drivers/net/setup.c - 1.17 linux/drivers/pci/pci.ids - 1.26 linux/drivers/usb/dabusb.c - 1.9 linux/drivers/usb/scanner.c - 1.18 linux/drivers/usb/usbmouse.c - 1.9 linux/drivers/usb/usbkbd.c - 1.12 linux/drivers/usb/ov511.c - 1.19 linux/drivers/usb/hid.c - 1.21 linux/net/decnet/dn_table.c - 1.4 linux/drivers/ieee1394/ohci1394.h - 1.7 linux/drivers/ieee1394/ohci1394.c - 1.9 linux/drivers/ieee1394/hosts.h - 1.4 linux/drivers/ieee1394/csr.c - 1.4 linux/drivers/ieee1394/Makefile - 1.5 linux/drivers/usb/ibmcam.c - 1.10 linux/arch/ia64/kernel/head.S - 1.6 linux/arch/ia64/kernel/fw-emu.c - 1.5 linux/arch/ia64/kernel/entry.S - 1.10 linux/arch/ia64/kernel/efi.c - 1.9 linux/arch/ia64/kernel/acpi.c - 1.7 linux/arch/ia64/kernel/Makefile - 1.8 linux/arch/ia64/ia32/sys_ia32.c - 1.11 linux/arch/ia64/ia32/ia32_entry.S - 1.9 linux/arch/ia64/ia32/binfmt_elf32.c - 1.8 linux/arch/ia64/ia32/Makefile - 1.6 linux/arch/ia64/hp/hpsim_setup.c - 1.3 linux/arch/ia64/hp/Makefile - 1.3 linux/arch/ia64/dig/setup.c - 1.5 linux/arch/ia64/dig/iosapic.c - 1.7 linux/arch/ia64/tools/print_offsets.c - 1.5 linux/arch/ia64/dig/Makefile - 1.4 linux/arch/ia64/config.in - 1.15 linux/arch/ia64/boot/Makefile - 1.4 linux/arch/ia64/Makefile - 1.7 linux/arch/ia64/kernel/irq.c - 1.10 linux/arch/ia64/sn/Makefile - 1.3 linux/arch/ia64/sn/sn1/Makefile - 1.3 linux/arch/ia64/kernel/setup.c - 1.7 linux/arch/ia64/kernel/signal.c - 1.7 linux/arch/ia64/kernel/smp.c - 1.7 linux/arch/ia64/kernel/sys_ia64.c - 1.5 linux/arch/ia64/kernel/time.c - 1.8 linux/arch/ia64/kernel/traps.c - 1.8 linux/arch/ia64/kernel/unaligned.c - 1.6 linux/arch/ia64/kernel/unwind.c - 1.5 linux/arch/ia64/lib/Makefile - 1.6 linux/arch/ia64/kernel/ivt.S - 1.8 linux/arch/ia64/sn/sn1/setup.c - 1.4 linux/arch/ia64/lib/copy_user.S - 1.5 linux/arch/ia64/kernel/machvec.c - 1.3 linux/arch/ia64/sn/sn1/irq.c - 1.3 linux/arch/ia64/kernel/pci.c - 1.5 linux/arch/ia64/kernel/sal.c - 1.5 linux/arch/ia64/kernel/ptrace.c - 1.6 linux/arch/ia64/kernel/process.c - 1.7 linux/arch/ia64/kernel/perfmon.c - 1.5 linux/arch/ia64/mm/tlb.c - 1.6 linux/arch/ia64/kernel/mca.c - 1.5 linux/arch/ia64/mm/init.c - 1.8 linux/arch/ia64/lib/flush.S - 1.3 linux/arch/ia64/mm/fault.c - 1.4 linux/arch/ia64/mm/Makefile - 1.2 linux/arch/ia64/kernel/mca_asm.S - 1.5 linux/arch/ia64/kernel/pal.S - 1.5 linux/arch/ia64/kernel/pci-dma.c - 1.7 linux/include/asm-ia64/iosapic.h - 1.3 linux/include/asm-ia64/io.h - 1.5 linux/include/linux/rtc.h - 1.4 linux/include/asm-ia64/ia32.h - 1.7 linux/include/asm-ia64/efi.h - 1.5 linux/include/asm-ia64/delay.h - 1.3 linux/include/asm-ia64/cache.h - 1.3 linux/include/asm-ia64/acpi-ext.h - 1.4 linux/include/asm-ia64/a.out.h - 1.2 linux/include/asm-ia64/mman.h - 1.3 linux/include/asm-ia64/sal.h - 1.5 linux/include/asm-ia64/processor.h - 1.9 linux/include/asm-ia64/pgtable.h - 1.10 linux/include/asm-ia64/pgalloc.h - 1.5 linux/include/asm-ia64/machvec.h - 1.4 linux/include/asm-ia64/machvec_dig.h - 1.3 linux/include/asm-ia64/machvec_hpsim.h - 1.3 linux/include/asm-ia64/pci.h - 1.7 linux/include/asm-ia64/page.h - 1.8 linux/include/asm-ia64/offsets.h - 1.8 linux/include/asm-ia64/shmparam.h - 1.2 linux/include/asm-ia64/ptrace.h - 1.6 linux/include/asm-ia64/machvec_init.h - 1.3 linux/include/asm-ia64/machvec_sn1.h - 1.2 linux/include/asm-ia64/mca.h - 1.3 linux/include/asm-ia64/mmu_context.h - 1.5 linux/include/asm-ia64/spinlock.h - 1.6 linux/include/asm-ia64/unistd.h - 1.9 linux/include/asm-ia64/uaccess.h - 1.5 linux/include/asm-ia64/system.h - 1.6 linux/drivers/char/amiserial.c - 1.7 linux/drivers/net/tulip/tulip_core.c - 1.16 linux/drivers/net/tulip/media.c - 1.4 linux/drivers/net/ioc3-eth.c - 1.8 linux/include/linux/netfilter_ipv6.h - 1.3 linux/drivers/usb/wacom.c - 1.10 linux/drivers/usb/rio500.c - 1.7 linux/drivers/usb/pegasus.c - 1.13 linux/include/linux/usb.h - 1.13 linux/include/asm-ia64/hw_irq.h - 1.4 linux/drivers/parport/ChangeLog - 1.11 linux/arch/ia64/kernel/irq_ia64.c - 1.6 linux/drivers/ide/sis5513.c - 1.8 linux/drivers/ide/piix.c - 1.8 linux/drivers/ide/macide.c - 1.3 linux/drivers/ide/ide-pci.c - 1.10 linux/drivers/ide/ide-geometry.c - 1.7 linux/drivers/ide/ide-dma.c - 1.7 linux/drivers/ide/ide-cs.c - 1.4 linux/drivers/ide/ide-cd.h - 1.6 linux/drivers/ide/ide-cd.c - 1.10 linux/drivers/ide/hpt366.c - 1.6 linux/drivers/ide/hd.c - 1.7 linux/drivers/ide/cs5530.c - 1.4 linux/Documentation/DocBook/z8530book.tmpl - 1.2 linux/Documentation/DocBook/videobook.tmpl - 1.5 linux/drivers/usb/dsbr100.c - 1.7 linux/net/ipv4/netfilter/ipt_LOG.c - 1.6 linux/include/linux/netfilter_ipv4/lockhelp.h - 1.2 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.6 linux/drivers/usb/mdc800.c - 1.7 linux/arch/i386/kernel/pci-irq.c - 1.10 linux/drivers/usb/serial/keyspan_pda.c - 1.10 linux/drivers/usb/serial/ftdi_sio.c - 1.11 linux/drivers/usb/serial/whiteheat.c - 1.9 linux/drivers/usb/serial/visor.c - 1.10 linux/arch/ia64/kernel/minstate.h - 1.4 linux/arch/ia64/ia32/ia32_traps.c - 1.3 linux/drivers/usb/serial/omninet.c - 1.8 linux/drivers/sound/i810_audio.c - 1.7 linux/drivers/usb/serial/digi_acceleport.c - 1.8 linux/Documentation/DocBook/mousedrivers.tmpl - 1.2 linux/drivers/char/drm/r128_drv.h - 1.3 linux/drivers/char/drm/r128_drv.c - 1.5 linux/drivers/char/drm/r128_drm.h - 1.3 linux/drivers/char/drm/r128_dma.c - 1.4 linux/drivers/char/drm/r128_context.c - 1.3 linux/drivers/char/drm/r128_bufs.c - 1.3 linux/drivers/char/drm/mga_drv.h - 1.5 linux/drivers/usb/storage/debug.h - 1.4 linux/drivers/usb/serial/keyspan.h - 1.4 linux/drivers/usb/microtek.c - 1.5 linux/drivers/acpi/namespace/nsxfobj.c - 1.4 linux/drivers/usb/bluetooth.c - 1.6 linux/drivers/acpi/hardware/hwcpu32.c - 1.4 linux/arch/ia64/ia32/ia32_ioctl.c - 1.2 linux/arch/ia64/kernel/ia64_ksyms.c - 1.4 linux/drivers/ieee1394/video1394.c - 1.4 linux/drivers/ieee1394/video1394.h - 1.3 linux/arch/ia64/lib/io.c - 1.3 linux/arch/ia64/lib/memcpy.S - 1.3 linux/fs/smbfs/smb_debug.h - 1.2 linux/drivers/sound/cs46xx.c - 1.5 linux/drivers/media/video/videodev.c - 1.2 linux/drivers/media/video/cpia_usb.c - 1.4 linux/drivers/media/radio/radio-zoltrix.c - 1.4 linux/drivers/media/radio/radio-typhoon.c - 1.4 linux/drivers/media/radio/radio-trust.c - 1.4 linux/drivers/media/radio/radio-terratec.c - 1.4 linux/drivers/media/radio/radio-sf16fmi.c - 1.4 linux/drivers/media/radio/radio-rtrack2.c - 1.4 linux/drivers/media/radio/radio-aztech.c - 1.4 linux/drivers/media/radio/radio-aimslab.c - 1.4 linux/drivers/char/joystick/iforce.c - 1.3 linux/drivers/md/raid5.c - 1.7 linux/drivers/block/cciss.c - 1.3 linux/drivers/usb/net1080.c - 1.4 linux/drivers/ide/osb4.c - 1.2 linux/include/asm-ia64/acpikcfg.h - 1.2 linux/include/asm-ia64/module.h - 1.2 linux/include/linux/zorro_ids.h - 1.2 linux/drivers/usb/serial/belkin_sa.c - 1.2 linux/drivers/usb/serial/empeg.c - 1.2 linux/drivers/scsi/osst.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jan 5 10:58:14 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 10:58:04 -0800 Received: from mail.connex.com ([216.100.236.3]:45837 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 10:57:50 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 10:54:52 -0800 Message-ID: From: Dale Stephenson To: Scott Smyth , 'Rajagopal Ananthanarayanan ' Cc: "''linux-xfs@oss.sgi.com ' '" , Dale Stephenson , "'neilb@cse.unsw.edu.au '" Subject: RE: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM Date: Fri, 5 Jan 2001 10:54:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Just to clarify: The resync _never_ finishes after we kill it by doing a mkfs.xfs on a logical volume on a RAID 5. If we let the sync finish before calling mkfs.xfs, there is no problem. With the resync daemon hung we can continue to use the RAID normally, although the sync never progresses. A reboot never completes because it can't get rid of raid5syncd, which is in uninterruptible sleep. FYI, here's my processor info: ---------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Celeron (Coppermine) stepping : 3 cpu MHz : 564.849 cache size : 128 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 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1127.22 -------------------- > -----Original Message----- > From: Scott Smyth [mailto:SSmyth@Connex.com] > Sent: Friday, January 05, 2001 10:13 AM > To: 'Rajagopal Ananthanarayanan '; Scott Smyth > Cc: ''linux-xfs@oss.sgi.com ' '; Dale Stephenson; > 'neilb@cse.unsw.edu.au > ' > Subject: RE: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in > kernel w/ LVM > > > Hi; > > The problem is that the resync _never_ finishes. I mean > never. Or are you saying you took the sse code for the > MMX out of something besides the xor.h? > > With our one patch, we can get it started but the > resync never goes forward. > > thanks, Scott > > -----Original Message----- > From: Rajagopal Ananthanarayanan > To: Scott Smyth > Cc: 'linux-xfs@oss.sgi.com '; Dale Stephenson; neilb@cse.unsw.edu.au > Sent: 1/5/01 10:06 AM > Subject: Re: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) > XFS in kernel > w/ LVM > > Scott Smyth wrote: > > > > Hi; > > > > Now that LVM is in the SGI tree, we would like to > > find out if anybody is seeing similar issues > > around RAID 5 software support and the complaints > > of mount with XFS in the kernel and trying to mount > > LVM volumes: > > > > LVM 0.9 (obviously) > > 2.4.0-test13-pre3 and 2.4.0-prerelease > > > > First, there are two problems we seem to have with > > RAID 5 with LVM on top and XFS as the file system. > > The first is that the MMX optimization in xor.h > > fails and keeps the xor module from even loading > > properly (see attached patch to avoid this). Having > > gotten around that, we then have a problem with > > the rsync daemon. We get a kernel oops (we have not > > had time to use kdb on it yet but will) on the > > starting the raid, but you can still proceed and > > use it. However, it never resyncs nor makes any > > progress to resync according to /proc/mdstat. Then, > > at shutdown of the raidset (or attempted), the > > raid stop hangs. We will give more info as we debug, > > but it is 100% reproduceable. > > > [ ... ] > > Hi, > > We have seen similar issues both w.r.t the sse optimizations > and w.r.t re-syncing. The sse issue surfaced when the raid > code got re-worked to factor out some of the architecture/processor > specific optimizations. I don't know if accessing the device > while resyncing is intented to work. One workaround for the > resync problem is to wait for the raid to finish resyncing; > the status, as you noted, is reported in /proc/mdstat. > > In our test box, the processor is: > > ---------- > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 7 > model name : Pentium III (Katmai) > stepping : 2 > cpu MHz : 500.141 > 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 : 996.15 > -------------------- > > I'll cc: Neil Brown who seems to be actively maintaining > the RAID subsystem. > > thanks, > > -------------------------------------------------------------- > ---------- > -- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------- > ---------- > -- > From owner-linux-xfs@oss.sgi.com Fri Jan 5 17:54:46 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 17:54:36 -0800 Received: from garnet.sover.net ([209.198.87.53]:1500 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 17:54:27 -0800 Received: from [192.168.1.3] (pm1a17.stj.sover.net [209.198.94.17]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id UAA27008 for ; Fri, 5 Jan 2001 20:54:22 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a17.stj.sover.net [209.198.94.17] 209.198.94.17 Fri, 5 Jan 2001 20:54:22 -0500 (EST) Date: Fri, 5 Jan 2001 20:59:25 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: SGI XFS Mailing List Subject: Error building 2.4.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Greetings all, I get this error when building 2.4.0..obviously XFS related... gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i586 -DEXPORT_SYMTAB -c procfs_syms.c rm -f proc.o ld -m elf_i386 -r -o proc.o inode.o root.o base.o generic.o array.o kmsg.o proc_tty.o proc_misc.o kcore.o procfs_syms.o make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' make -C xfs make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make -C linux make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' make all_targets make[4]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' make[4]: *** No rule to make target `../pseudo-inc/sys/dirent.h', needed by `../xfs.h'. Stop. I hope that is specific enough..I am not a developer myself (not yet) so I might not have pertinant information here :) btw, I had no problems with any kernel in the CVS tree since I started keeping up with it, since um...2.4test11. Hope this helps guys! RegEx From owner-linux-xfs@oss.sgi.com Fri Jan 5 18:02:47 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 18:02:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38425 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 18:02:31 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA09154 for ; Fri, 5 Jan 2001 18:11:12 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f061xfv02589; Fri, 5 Jan 2001 19:59:41 -0600 Message-ID: <3A567C0D.55E44519@thebarn.com> Date: Fri, 05 Jan 2001 19:59:41 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker CC: SGI XFS Mailing List Subject: Re: Error building 2.4.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: you need to do a make depend if that doesn't work save your .config make mrproper restore .conf make oldconfig depend bzImage modules. > Greetings all, > > I get this error when building 2.4.0..obviously XFS related... > > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i586 -DEXPORT_SYMTAB -c procfs_syms.c > rm -f proc.o > ld -m elf_i386 -r -o proc.o inode.o root.o base.o generic.o array.o kmsg.o proc_tty.o proc_misc.o kcore.o procfs_syms.o > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > make -C xfs > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > make -C linux > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' > make all_targets > make[4]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' > make[4]: *** No rule to make target `../pseudo-inc/sys/dirent.h', needed by `../xfs.h'. Stop. > > I hope that is specific enough..I am not a developer myself (not yet) so I might not have pertinant information here :) > btw, I had no problems with any kernel in the CVS tree since I started keeping up with it, since um...2.4test11. Hope this helps guys! > > RegEx -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Jan 5 18:26:57 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 18:26:47 -0800 Received: from garnet.sover.net ([209.198.87.53]:44024 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 18:26:27 -0800 Received: from [192.168.1.3] (pm1a17.stj.sover.net [209.198.94.17]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id VAA10059; Fri, 5 Jan 2001 21:26:19 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a17.stj.sover.net [209.198.94.17] 209.198.94.17 Fri, 5 Jan 2001 21:26:19 -0500 (EST) Date: Fri, 5 Jan 2001 21:31:23 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Russell Cattelan cc: SGI XFS Mailing List Subject: Re: Error building 2.4.0 In-Reply-To: <3A567C0D.55E44519@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 5 Jan 2001, Russell Cattelan wrote: oops! so sorry! I hadn't run a make dep cause it didn't say to..just said to go ahead and build it..my bad, and thanks for pointing out my ignorance :) RegEx > Jason Walker wrote: > > you need to do a make depend > if that doesn't work save your .config > make mrproper > restore .conf > make oldconfig depend bzImage modules. > > > > Greetings all, > > > > I get this error when building 2.4.0..obviously XFS related... > > > > gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i586 -DEXPORT_SYMTAB -c procfs_syms.c > > rm -f proc.o > > ld -m elf_i386 -r -o proc.o inode.o root.o base.o generic.o array.o kmsg.o proc_tty.o proc_misc.o kcore.o procfs_syms.o > > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/proc' > > make -C xfs > > make[2]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > > make -C linux > > make[3]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' > > make all_targets > > make[4]: Entering directory `/usr/src/linux-2.4-xfs/linux/fs/xfs/linux' > > make[4]: *** No rule to make target `../pseudo-inc/sys/dirent.h', needed by `../xfs.h'. Stop. > > > > I hope that is specific enough..I am not a developer myself (not yet) so I might not have pertinant information here :) > > btw, I had no problems with any kernel in the CVS tree since I started keeping up with it, since um...2.4test11. Hope this helps guys! > > > > RegEx > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. > > > From owner-linux-xfs@oss.sgi.com Fri Jan 5 19:21:47 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 19:21:37 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:46457 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 19:21:23 -0800 Received: from chuckle.americas.sgi.com (128-162-184-123.americas.sgi.com [128.162.184.123]) 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 TAA02261 for ; Fri, 5 Jan 2001 19:21:19 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f063Ipv02799 for ; Fri, 5 Jan 2001 21:18:51 -0600 Message-ID: <3A568E9B.F7D842DC@thebarn.com> Date: Fri, 05 Jan 2001 21:18:51 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Prerelease-test1-rc1 XFS install CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Ok I've been promising something for a few days now. And the verdict! We'll it still isn't quite ready. The latest 2.4.0 version of the kernel has problems with python but then doesn't everybody :-) :-). For anybody who is just dying to get their system up and running XFS only, have put the a version of the iso image on oss. ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test.iso Note the kernels installed will be based on 2.4.0-test11, which was not a very stable release, I recommend updating to a newer kernel. I will put our latest rpm out on oss also. Note this has not been tested on many machines... ok two and it fails on one. :-( The initrd fails to build at install time, this seem to be a problem with the loop device code in the install kernel. I am hoping the 2.4.0 kernel fixes the problem, soon as I get past the installer problems. This images is a good candidate for your CD-RW or the 50 for a $1 type CD's The good news: if the install works it is fairly trivial to upgrade to the latest kernel. Ohh Ya this CD only contains updated rpm images, you will need a copy of the RedHat 7.0 disk 1 and 2 to actually do the install. Please forward and success our way. I'm sure there will be failures minds as well send them also. Also note the images for floppy installs are on the CD, but don't bother trying them... they don't work. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Jan 5 22:13:07 2001 Received: by oss.sgi.com id ; Fri, 5 Jan 2001 22:12:58 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53023 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 5 Jan 2001 22:12:47 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08811 for ; Fri, 5 Jan 2001 22:21:27 -0800 (PST) mail_from (sandeen@sgi.com) Received: from sgi.com (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA88003 for ; Fri, 5 Jan 2001 22:06:13 -0800 (PST) Message-ID: <3A56B745.B9B95004@sgi.com> Date: Sat, 06 Jan 2001 00:12:21 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD References: <3A568E9B.F7D842DC@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > > Ok I've been promising something for a few days now. > And the verdict! We'll it still isn't quite ready. Also note that the way to get to the XFS format option is to do a "custom" install - if you let the installer do everything for you, you may never see the XFS option. Choose "custom" and the XFS formatting option will show up after partitioning, during the formatting dialog. And if anyone knows why fork()ing python fails with the latest 2.4, please do drop us a line. :) -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 6 10:03:09 2001 Received: by oss.sgi.com id ; Sat, 6 Jan 2001 10:02:59 -0800 Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:62982 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Sat, 6 Jan 2001 10:02:49 -0800 Received: from lupo.thebarn.com (localhost [127.0.0.1]) by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id f06I2iM04657; Sat, 6 Jan 2001 12:02:45 -0600 (CST) (envelope-from cattelan@thebarn.com) Date: Sat, 06 Jan 2001 12:02:44 -0600 Message-ID: From: cattelan@thebarn.com To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD In-Reply-To: <3A56B745.B9B95004@sgi.com> References: <3A568E9B.F7D842DC@thebarn.com> <3A56B745.B9B95004@sgi.com> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I've got a fortest prgram that seems to work just fine I'm going to boot of the CD and see I can figure out why it it is failing during install. #!/usr/bin/python import sys, os, signal if (os.path.exists('isys')): sys.path.append('edd') sys.path.append('libfdisk') sys.path.append('balkan') sys.path.append('gnome-map') sys.path.append('isys') sys.path.append('textw') sys.path.append('iw') sys.path.append('installclasses') sys.path.append('edd') else: sys.path.append('/usr/lib/anaconda') sys.path.append('/usr/lib/anaconda/textw') sys.path.append('/usr/lib/anaconda/iw') sys.path.append('/usr/lib/anaconda/installclasses') import isys import iutil loc = "/sbin/probe" result = iutil.execWithCapture(loc, [ loc ]) print "The result is", result From owner-linux-xfs@oss.sgi.com Sat Jan 6 12:34:50 2001 Received: by oss.sgi.com id ; Sat, 6 Jan 2001 12:34:40 -0800 Received: from note.orchestra.cse.unsw.EDU.AU ([129.94.242.29]:50186 "HELO note.orchestra.cse.unsw.EDU.AU") by oss.sgi.com with SMTP id ; Sat, 6 Jan 2001 12:34:29 -0800 Received: From notabene.cse.unsw.edu.au ([129.94.242.2] == beethoven.orchestra.cse.unsw.EDU.AU) (for ) (for ) (for ) (for ) (for ) By note With Smtp ; Sun, 7 Jan 2001 07:34:06 +1100 Received: from neilb by notabene.cse.unsw.edu.au with local (Exim 3.12 #1 (Debian)) id 14F02N-0002z1-00; Sun, 07 Jan 2001 07:34:03 +1100 From: Neil Brown To: Rajagopal Ananthanarayanan Date: Sun, 7 Jan 2001 07:34:02 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14935.33082.91468.373421@notabene.cse.unsw.edu.au> Cc: Scott Smyth , "'linux-xfs@oss.sgi.com '" , Dale Stephenson , neilb@cse.unsw.edu.au Subject: Re: LVM w/ XFS: 1) raid 5 issues (sync daemon) & 2) XFS in kernel w/ LVM In-Reply-To: message from Rajagopal Ananthanarayanan on Friday January 5 References: <3A560D3F.A8784FBF@sgi.com> X-Mailer: VM 6.72 under Emacs 20.7.2 X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D X-Orcpt: rfc822;linux-xfs-outgoing On Friday January 5, ananth@sgi.com wrote: > > I'll cc: Neil Brown who seems to be actively maintaining > the RAID subsystem. If you point me at a patch to apply to 2.4.0 and the source for the user space tools I will try to reproduce this and find out what it going on. NeilBrown From owner-linux-xfs@oss.sgi.com Sun Jan 7 18:51:22 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 18:51:12 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5972 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 18:50:58 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05168; Sun, 7 Jan 2001 18:59:41 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA83888; Sun, 7 Jan 2001 18:50:57 -0800 (PST) Date: Sun, 7 Jan 2001 18:50:57 -0800 (PST) Message-Id: <200101080250.SAA83888@info.engr.sgi.com> X-Pv-Incident: 803884 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 803884 - double-fault with HIGHMEM To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803884 *Status : closed Priority : 3 Assigned Engineer : dxm Submitter : dxm Opened Date : 10/04/00 *Closed Date : 01/07/01 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 01/07/01 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Oct 30 2000 09:07:30AM ========================== This bug appears to have been fixed in the base linux kernel. hoorah ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Jan 07 2001 06:50:57PM ========================== This is a linux problem, not an XFS problem. From owner-linux-xfs@oss.sgi.com Sun Jan 7 18:51:42 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 18:51:32 -0800 Received: from [204.94.214.10] ([204.94.214.10]:61477 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 18:51:29 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA19458; Sun, 7 Jan 2001 18:49:15 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA38310; Sun, 7 Jan 2001 18:50:06 -0800 (PST) Date: Sun, 7 Jan 2001 18:50:06 -0800 (PST) Message-Id: <200101080250.SAA38310@info.engr.sgi.com> X-Pv-Incident: 801095 webPV: proxy2.melbourne.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (dxm@engr.sgi.com) Subject: CLOSE 801095 - xfs_repair sucks memory in phase7 To: dxm@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095 *Status : closed Priority : 4 Assigned Engineer : dxm Submitter : dxm Opened Date : 09/06/00 *Closed Date : 01/07/01 *Fixed By : dxm *Fixed By Domain : engr *Modified Date : 01/07/01 *Modified User : dxm *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: dxm@engr (BugWorks) Date: Jan 07 2001 06:50:06PM ========================== From owner-linux-xfs@oss.sgi.com Sun Jan 7 20:29:23 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 20:29:13 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:31063 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 20:28:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA04369 for ; Sun, 7 Jan 2001 20:37:37 -0800 (PST) mail_from (dxm@snort.melbourne.sgi.com) Received: (from dxm@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA47103; Mon, 8 Jan 2001 15:27:34 +1100 (EST) Date: Mon, 8 Jan 2001 15:27:34 +1100 (EST) From: Daniel Moore Message-Id: <200101080427.PAA47103@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 810839 - make jdm_getfshandle follow symlinks Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fixes problems with dump/restore/bstat/fsr behaving badly on an FS mounted on a symlink. Modid: 2.4.x-xfs:slinx:81717a Date: Sun Jan 7 20:26:27 PST 2001 Workarea: snort:/home/dxm/isms/slinx-xfs Author: dxm The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/handle/jdm.c - 1.4 - pv 810839 - make jdm_getfshandle follow symlinks. From owner-linux-xfs@oss.sgi.com Sun Jan 7 21:03:23 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 21:03:13 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:63755 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 21:02:53 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@whitestar.arts.usyd.edu.au [129.78.16.20]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id QAA28055; Mon, 8 Jan 2001 16:02:41 +1100 (EST) Message-ID: <3A594AF3.40F7A9F1@arts.usyd.edu.au> Date: Mon, 08 Jan 2001 16:06:59 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD References: <3A568E9B.F7D842DC@thebarn.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms23BAB7F046CEE1F5EFE25F15" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms23BAB7F046CEE1F5EFE25F15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russell Cattelan wrote: > > Ok I've been promising something for a few days now. > And the verdict! We'll it still isn't quite ready. > > The latest 2.4.0 version of the kernel has problems with python > but then doesn't everybody :-) :-). > > For anybody who is just dying to get their system up and running > XFS only, have put the a version of the iso image on oss. > > ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test.iso > > Note the kernels installed will be based on 2.4.0-test11, which was > not a very stable release, I recommend updating to a newer kernel. > I will put our latest rpm out on oss also. > > Note this has not been tested on many machines... ok two and > it fails on one. :-( The initrd fails to build at install time, this > seem > to be a problem with the loop device code in the install kernel. > I am hoping the 2.4.0 kernel fixes the problem, soon as I get past the > installer problems. Ok, it died on my Dell :-( Ive got an Anaconda backtrace - KeyError hda3 fstab.py line 729 in mountFilesystems fstype=self.formatType[device[) > This images is a good candidate for your CD-RW or the 50 for a $1 type > CD's Mine cost $2AUS. :-) > Ohh Ya this CD only contains updated rpm images, you will need > a copy of the RedHat 7.0 disk 1 and 2 to actually do the install. At which point do you change in the disks ? > I'm sure there will be failures minds as well send them also. > > Also note the images for floppy installs are on the CD, but don't bother > > trying them... they don't work. I had a stab at modifing the bootnet.img but all I got was kernel panics. I was bumbing about in the dark trying to modify the boot floppy. -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University --------------ms23BAB7F046CEE1F5EFE25F15 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA4MDUwNzAxWjAjBgkq hkiG9w0BCQQxFgQUNciifUMbYObRJpQCDHPxSiG4K24wOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYC/3i1kxtczHfhpMr+OyEDdeYj83IZpenDECcwQYdH9OerI/5TZogLXEPtgVJwnF2pKbvi2 VALsOXRKO+fFJqTiilR1gYraWzx18VMe11K4+bJdEGhdmWBg7Kt7oLJRfzZm01yXUxWW/iWl msdRsVcK4nCKN404yXkks3frzO/66A== --------------ms23BAB7F046CEE1F5EFE25F15-- From owner-linux-xfs@oss.sgi.com Sun Jan 7 23:05:44 2001 Received: by oss.sgi.com id ; Sun, 7 Jan 2001 23:05:34 -0800 Received: from mail11.jump.net ([206.196.91.11]:13520 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Sun, 7 Jan 2001 23:05:29 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0875Sm13594 for ; Mon, 8 Jan 2001 01:05:28 -0600 (CST) Message-ID: <3A5966B2.5D14270C@sgi.com> Date: Mon, 08 Jan 2001 01:05:22 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD References: <3A568E9B.F7D842DC@thebarn.com> <3A594AF3.40F7A9F1@arts.usyd.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Matthew Geier wrote: > Ok, it died on my Dell :-( > > Ive got an Anaconda backtrace - > KeyError hda3 > fstab.py line 729 in mountFilesystems fstype=self.formatType[device[) Argh, I think I know what this is... do you have more of the backtrace so I can be sure? Out of curiosity, were you mixing ext2 and xfs partitions? (You should be able to, but there might be a thinko in there...) > > Ohh Ya this CD only contains updated rpm images, you will need > > a copy of the RedHat 7.0 disk 1 and 2 to actually do the install. > > At which point do you change in the disks ? After the backtrace. :) Seriously, when it starts installing RPMS it will prompt you to start switching disks. > I had a stab at modifing the bootnet.img but all I got was kernel > panics. I was bumbing about in the dark trying to modify the boot > floppy. Was your failure above with the bootnet.img image, or straight from the CD boot? -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 8 02:32:45 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 02:32:36 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:29449 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 02:32:14 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id VAA06492; Mon, 8 Jan 2001 21:30:51 +1100 (EST) Message-ID: <3A59970C.F2CCFBDF@arts.usyd.edu.au> Date: Mon, 08 Jan 2001 21:31:40 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD References: <3A568E9B.F7D842DC@thebarn.com> <3A594AF3.40F7A9F1@arts.usyd.edu.au> <3A5966B2.5D14270C@sgi.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms712BAFE48492E89565C2AE22" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms712BAFE48492E89565C2AE22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > > Matthew Geier wrote: > > > Ok, it died on my Dell :-( > > > > Ive got an Anaconda backtrace - > > KeyError hda3 > > fstab.py line 729 in mountFilesystems fstype=self.formatType[device[) > > Argh, I think I know what this is... do you have more of the backtrace > so I can be sure? I didnt record more unfortunatly. > Out of curiosity, were you mixing ext2 and xfs partitions? (You should > be able to, but there might be a thinko in there...) Yes. I tried to make /boot ext2 and not xfs. When I later tried both as XFS it worked, the system is now installed and running!. > > I had a stab at modifing the bootnet.img but all I got was kernel > > panics. I was bumbing about in the dark trying to modify the boot > > floppy. > > Was your failure above with the bootnet.img image, or straight from the > CD boot? I did't have the Redhat CDs at work, but images are on our network, so had a stab at bootneting it. 'pure' XFS it appears to be fine. I have a running system. However I have a 'new' problem. The permissions on /dev are wacked. Like some one has done a chown root:root *; chmod 0 * on /dev. I can only login as root, as user something fails due lack of /dev access. When I try to fix the permissions with MAKEDEV, it only partially does the job. Group changes don't stick at all. I am NOT using devfs. I might try recompiling with devfs :-) BTW, the machine is a Dell Inspriron C600. fbcon and xfree with the rage driver don't get along.... --------------ms712BAFE48492E89565C2AE22 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA4MTAzMTQ0WjAjBgkq hkiG9w0BCQQxFgQURTT4pXBeRphqCuq6DRDha5kld5YwOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYBv2m2U+xu8RAmTbst+qeDdgU2QeYpLi3fsqJlT2LbvrRZYTocQjGRnBE7kEPcGRKoBK8fh wTId8fnBoG+thQlmSAeQbG+vnxI69t9ktZq1zzwOtijKzeSQ5i2uuRu3YhylrOa1n1wQdMlQ 1xxPSOKo+4bwR0GX73OBq1H6gsGWGg== --------------ms712BAFE48492E89565C2AE22-- From owner-linux-xfs@oss.sgi.com Mon Jan 8 04:56:26 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 04:56:16 -0800 Received: from pike.sover.net ([209.198.87.34]:36846 "EHLO pike.sover.net") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 04:55:56 -0800 Received: from [192.168.1.3] (pm1a24.stj.sover.net [209.198.94.24]) by pike.sover.net (8.9.3/8.9.3) with ESMTP id HAA12843; Mon, 8 Jan 2001 07:55:46 -0500 (EST) Comments: SoVerNet Verification (on pike.sover.net) [192.168.1.3] from pm1a24.stj.sover.net [209.198.94.24] 209.198.94.24 Mon, 8 Jan 2001 07:55:46 -0500 (EST) Date: Mon, 8 Jan 2001 08:01:10 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Matthew Geier cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD (/dev permissions) In-Reply-To: <3A59970C.F2CCFBDF@arts.usyd.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I too have noticed some oddities with /dev permissions, similar to what you have expirianced. When I moved to an XFS /, my user did not have access to /dev/mixer so I chmod'd it and when I rebooted it didn't seem to stick. I wasn't going to post this until I could pin it down to something specific, but I had no time to do so and as you posted about it I thought I'd let you know you are not alone :) I am running 2.4.0 now, but this happened since um....2.4test13pre3 (when I moved to an XFS /) Just thought that might help :) RegEx On Mon, 8 Jan 2001, Matthew Geier wrote: > > 'pure' XFS it appears to be fine. I have a running system. However I > have a 'new' problem. The permissions on /dev are wacked. Like some one > has done a chown root:root *; chmod 0 * on /dev. I can only login as > root, as user something fails due lack of /dev access. When I try to fix > the permissions with MAKEDEV, it only partially does the job. Group > changes don't > stick at all. > > I am NOT using devfs. I might try recompiling with devfs :-) From owner-linux-xfs@oss.sgi.com Mon Jan 8 06:31:27 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 06:31:08 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:10003 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 06:31:06 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14FdK2-0006TQ-00 for linux-xfs@oss.sgi.com; Mon, 08 Jan 2001 15:30:54 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14FdK0-00008g-00 for ; Mon, 08 Jan 2001 15:30:52 +0100 Date: Mon, 8 Jan 2001 15:30:52 +0100 From: Jens Axboe To: linux-xfs@oss.sgi.com Subject: IDE kiobuf Message-ID: <20010108153052.C322@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, Was [subj] ever merged into the current tree, or lost for good? -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Mon Jan 8 08:27:48 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 08:27:38 -0800 Received: from tux.mkp.net ([130.225.60.11]:54533 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 08:27:24 -0800 Received: from bentley.socsci.auc.dk ([130.225.60.48] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14Ff8e-0000WV-00; Mon, 08 Jan 2001 17:27:16 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id LAA02079; Mon, 8 Jan 2001 11:28:22 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Jens Axboe Cc: linux-xfs@oss.sgi.com Subject: Re: IDE kiobuf References: <20010108153052.C322@suse.de> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Jan 2001 11:28:22 -0500 In-Reply-To: Jens Axboe's message of "Mon, 8 Jan 2001 15:30:52 +0100" Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Jens" == Jens Axboe writes: Jens> Was [subj] ever merged into the current tree, or lost for good? I'm going to merge it in today. I was about to check it in last week, but then I corrupted the drive due to a bug in my LVM code. Gack. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Mon Jan 8 11:32:09 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 11:32:00 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:20288 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 11:31:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.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 LAA03484 for ; Mon, 8 Jan 2001 11:31:51 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA388453; Mon, 8 Jan 2001 13:30:32 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA40836; Mon, 8 Jan 2001 13:30:32 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id f08JUWG20194; Mon, 8 Jan 2001 13:30:32 -0600 Message-ID: <3A5A1557.2B1DE950@thebarn.com> Date: Mon, 08 Jan 2001 13:30:31 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Geier CC: linux-xfs@oss.sgi.com Subject: Re: Prerelease-test1-rc1 XFS install CD References: <3A568E9B.F7D842DC@thebarn.com> <3A594AF3.40F7A9F1@arts.usyd.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Matthew Geier wrote: > > Russell Cattelan wrote: > > > > Ok I've been promising something for a few days now. > > And the verdict! We'll it still isn't quite ready. > > > > The latest 2.4.0 version of the kernel has problems with python > > but then doesn't everybody :-) :-). > > > > For anybody who is just dying to get their system up and running > > XFS only, have put the a version of the iso image on oss. > > > > ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test.iso > > > > Note the kernels installed will be based on 2.4.0-test11, which was > > not a very stable release, I recommend updating to a newer kernel. > > I will put our latest rpm out on oss also. > > > > Note this has not been tested on many machines... ok two and > > it fails on one. :-( The initrd fails to build at install time, this > > seem > > to be a problem with the loop device code in the install kernel. > > I am hoping the 2.4.0 kernel fixes the problem, soon as I get past the > > installer problems. > > Ok, it died on my Dell :-( > > Ive got an Anaconda backtrace - > KeyError hda3 > fstab.py line 729 in mountFilesystems fstype=self.formatType[device[) > > > This images is a good candidate for your CD-RW or the 50 for a $1 type > > CD's > > Mine cost $2AUS. :-) > > > Ohh Ya this CD only contains updated rpm images, you will need > > a copy of the RedHat 7.0 disk 1 and 2 to actually do the install. > > At which point do you change in the disks ? > > > I'm sure there will be failures minds as well send them also. > > > > Also note the images for floppy installs are on the CD, but don't bother > > > > trying them... they don't work. > > I had a stab at modifing the bootnet.img but all I got was kernel > panics. I was bumbing about in the dark trying to modify the boot > floppy. The boot floppy its self should be ok... the problem is with the netstg1/2.img mkfs.xfs isn't showing up for some reason. I think is has something to do with a lack of space. > > -- > Matthew Geier matthew@arts.usyd.edu.au > Arts IT Unit +61 2 9351 4713 > Sydney University -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Jan 8 14:23:28 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 14:23:19 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:64262 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 14:23:14 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14Fkgn-0000hx-00; Mon, 08 Jan 2001 23:22:53 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Fkgl-0000jB-00; Mon, 08 Jan 2001 23:22:51 +0100 Date: Mon, 8 Jan 2001 23:22:51 +0100 From: Jens Axboe To: "Martin K. Petersen" Cc: linux-xfs@oss.sgi.com Subject: Re: IDE kiobuf Message-ID: <20010108232251.J359@suse.de> References: <20010108153052.C322@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from mkp@linuxcare.com on Mon, Jan 08, 2001 at 11:28:22AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 08 2001, Martin K. Petersen wrote: > Jens> Was [subj] ever merged into the current tree, or lost for good? > > I'm going to merge it in today. I was about to check it in last week, > but then I corrupted the drive due to a bug in my LVM code. Gack. Ok excellent, I was just wondering whether I needed to update it for latest CVS. But it seems you've got that handled, great :-) -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Mon Jan 8 15:24:19 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 15:23:59 -0800 Received: from tux.mkp.net ([130.225.60.11]:20232 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 15:23:46 -0800 Received: from bentley.socsci.auc.dk ([130.225.60.48] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14Fldd-0000sz-00; Tue, 09 Jan 2001 00:23:41 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id SAA02212; Mon, 8 Jan 2001 18:24:47 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: linux-xfs@oss.sgi.com Subject: TAKE - kiobuf IDE support From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Jan 2001 18:24:47 -0500 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jan 8 15:21:53 PST 2001 Workarea: sshgate.corp.sgi.com:/home/mkp/XFS/slinx-axboe The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81740a linux/include/linux/major.h - 1.24 linux/include/linux/blkdev.h - 1.27 linux/drivers/block/ll_rw_blk.c - 1.58 linux/include/linux/ide.h - 1.26 linux/drivers/ide/pdc4030.c - 1.3 linux/drivers/ide/ide.c - 1.16 linux/drivers/ide/ide-probe.c - 1.11 linux/drivers/ide/ide-dma.c - 1.8 linux/drivers/ide/ide-disk.c - 1.10 linux/fs/pagebuf/page_buf_io.c - 1.39 - kiobuf IDE support from Jens Axboe -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Mon Jan 8 18:57:29 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 18:57:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:9596 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 18:57:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA27638 for ; Mon, 8 Jan 2001 18:56:08 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA392648 for ; Mon, 8 Jan 2001 20:55:44 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA56215 for ; Mon, 8 Jan 2001 20:55:44 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f092ti021563 for linux-xfs@oss.sgi.com; Mon, 8 Jan 2001 20:55:44 -0600 Date: Mon, 8 Jan 2001 20:55:44 -0600 From: Russell Cattelan Message-Id: <200101090255.f092ti021563@gibble.americas.sgi.com> Subject: TAKE - Remove -g3 flags. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jan 8 18:55:07 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81758a linux/fs/xfs/Makefile - 1.113 linux/fs/xfs/linux/Makefile - 1.34 linux/fs/pagebuf/Makefile - 1.4 linux/fs/xfs/support/Makefile - 1.4 - Remove the -g3 from the compile flags. This shouldn't be the default at this point, anybody needed debugging info should add them by hand. This should significatly reduce the size of the initial ram disks. From owner-linux-xfs@oss.sgi.com Mon Jan 8 19:23:29 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 19:23:20 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:29197 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 19:23:06 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA04340 for ; Mon, 8 Jan 2001 19:23:03 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA63492 for linux-xfs@oss.sgi.com; Tue, 9 Jan 2001 14:21:44 +1100 (EST) Date: Tue, 9 Jan 2001 14:21:44 +1100 (EST) From: Nathan Scott Message-Id: <200101090321.OAA63492@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:81757a Date: Mon Jan 8 19:21:15 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/Makefile - 1.35 - remove xfs_mount_opt.o. linux/fs/xfs/linux/xfs_linux.h - 1.39 - remove no longer needed prototypes. linux/fs/xfs/linux/xfs_super.c - 1.104 - merge in mount option parsing code - this is only used here, so should be a static, not off in its own file - make it so (consistent with other fs code too). From owner-linux-xfs@oss.sgi.com Mon Jan 8 22:37:21 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 22:37:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:57417 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 22:36:59 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.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 WAA04648 for ; Mon, 8 Jan 2001 22:36:54 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id AAA394288 for ; Tue, 9 Jan 2001 00:35:38 -0600 (CST) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id AAA37652 for ; Tue, 9 Jan 2001 00:35:38 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.10.1) id f096ZcL22355 for linux-xfs@oss.sgi.com; Tue, 9 Jan 2001 00:35:38 -0600 Date: Tue, 9 Jan 2001 00:35:38 -0600 From: Russell Cattelan Message-Id: <200101090635.f096ZcL22355@gibble.americas.sgi.com> Subject: TAKE - RedHat anaconda patches To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jan 8 22:34:40 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81765a SOURCES/anaconda-7.1-xfs.patch - 1.1 SOURCES/anaconda_header.png - 1.1 SOURCES/first-375.png - 1.1 SOURCES/first.png - 1.1 SOURCES/mkinitrd-2.8-xfs.patch - 1.1 SOURCES/splash.png - 1.1 SPECS/anaconda-7.1-xfs.spec - 1.1 SPECS/mkinitrd-xfs.spec - 1.1 - Patch to enable XFS support From owner-linux-xfs@oss.sgi.com Mon Jan 8 22:53:42 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 22:53:32 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13947 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 22:53:09 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA11298 for ; Mon, 8 Jan 2001 22:52:16 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f096oXv22105 for ; Tue, 9 Jan 2001 00:50:33 -0600 Message-ID: <3A5AB4B9.C6AA3A53@thebarn.com> Date: Tue, 09 Jan 2001 00:50:33 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RedHat 7.0 XFS-prerelease-test2-rc2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I put a new iso images up on oss. ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test2.iso Things fixed. file systems types can now be mixed ie some xfs some ext2 installed kernels are now 2.4.0 based NOTE kernel during install process is still test11 based. ftp, http and nfs installs via floppy now work. Significantly reduced ram disk sizes... should work better on small mem systems. Note I don't have many plans to look into X related install problems. We haven't touched this area of the installer so any problems are RH problems, and hopefully will be fixed by the RH people. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Jan 9 01:36:13 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 01:36:03 -0800 Received: from edge.coltex.nl ([194.151.97.115]:65287 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 01:35:43 -0800 Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171]) by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id f099ZfZ25639 for ; Tue, 9 Jan 2001 10:35:41 +0100 Message-Id: <4.3.2.7.2.20010109102406.035b4a70@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jan 2001 10:33:26 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Compiling 2.4.0 with "gcc-2.96" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, If I try to compile the kernel with gcc-2.96-69 (the updated rpm for redhat 7) it butts out in xfs_bmap.c This was just a test to checksee if it would compile at all. If someone is capable of interpreting what this error means, if it could possibly be fixed (for both compilers ofcourse) should it even be a bug. The kernel compiles fine using 2.91.66 ofcourse. I'm just trying to see what a kernel would look like when compiled with "gcc-2.96" ;-) gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -Wno-unused -Wno-parentheses -Wno-uninitialized -I. -funsigned-char -Wno-unknown-pragmas -c -o xfs_bmap.o xfs_bmap.c xfs_bmap.c:543:36: warning: pasting would not give a valid preprocessing token xfs_bmap.c:2830:36: warning: pasting would not give a valid preprocessing token xfs_bmap.c: In function `xfs_bmap_del_extent': xfs_bmap.c:3130: Unrecognizable insn: (insn/i 254 252 4392 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 266)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 266)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (nil) (nil)) xfs_bmap.c:3130: confused by earlier errors, bailing out make[3]: *** [xfs_bmap.o] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_dir_fs] Error 2 Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Tue Jan 9 10:41:36 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 10:41:16 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:26967 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 10:41:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA11304 for ; Tue, 9 Jan 2001 10:40:12 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA91035 for ; Tue, 9 Jan 2001 12:39:48 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f09Icml24757 for linux-xfs@oss.sgi.com; Tue, 9 Jan 2001 12:38:48 -0600 Date: Tue, 9 Jan 2001 12:38:48 -0600 From: Russell Cattelan Message-Id: <200101091838.f09Icml24757@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This mod didn't seem to make much sense. It's less modular Besides the mount option code should be cleaned up rather than merged. Date: Tue Jan 9 10:38:27 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean Undoes mod: 2.4.x-xfs:slinx:81757a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81778a linux/fs/xfs/linux/xfs_linux.h - 1.40 linux/fs/xfs/linux/Makefile - 1.36 linux/fs/xfs/linux/xfs_super.c - 1.105 From owner-linux-xfs@oss.sgi.com Tue Jan 9 11:03:08 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 11:02:48 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:19820 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 11:02:24 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA18449 for ; Tue, 9 Jan 2001 11:01:30 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA10296 for ; Tue, 9 Jan 2001 13:01:07 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f09J07D25825 for linux-xfs@oss.sgi.com; Tue, 9 Jan 2001 13:00:07 -0600 Date: Tue, 9 Jan 2001 13:00:07 -0600 From: Russell Cattelan Message-Id: <200101091900.f09J07D25825@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing revive file. Date: Tue Jan 9 10:59:04 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean Undoes mod: 2.4.x-xfs:slinx:81759a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81780a linux/fs/xfs/linux/xfs_mount_opt.c - 1.20 From owner-linux-xfs@oss.sgi.com Tue Jan 9 12:38:58 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 12:38:38 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:19467 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 12:38:29 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09842 for ; Tue, 9 Jan 2001 12:47:14 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA44375; Tue, 9 Jan 2001 12:32:58 -0800 (PST) Message-ID: <3A5B760B.A80AEC40@sgi.com> Date: Tue, 09 Jan 2001 12:35:23 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: RedHat 7.0 XFS-prerelease-test2-rc2 References: <3A5AB4B9.C6AA3A53@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > > I put a new iso images up on oss. > ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test2.iso > > Things fixed. > file systems types can now be mixed > ie some xfs some ext2 > installed kernels are now 2.4.0 based > NOTE kernel during install process is still test11 based. > > ftp, http and nfs installs via floppy now work. > > Significantly reduced ram disk sizes... should work better > on small mem systems. > > Note I don't have many plans to look into X related install problems. > We haven't touched this area of the installer so any problems > are RH problems, and hopefully will be fixed by the RH people. The new images work fine on a test system here (64MB, 2P). Looks like mkinitrd problems are gone now, since the modules are _much_ less bulky with no g3. I'll look to reproduce the bug by putting back g3 & increasing module sizes ... ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jan 9 15:29:57 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 15:29:37 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:56614 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 15:29:27 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA23237 for ; Tue, 9 Jan 2001 15:28:33 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.9.3/8.9.3) id KAA10509; Wed, 10 Jan 2001 10:28:17 +1100 Date: Wed, 10 Jan 2001 10:28:17 +1100 From: Keith Owens Message-Id: <200101092328.KAA10509@sherman.melbourne.sgi.com> Subject: TAKE - Export req_finished_io for SCSI as a module To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing When SCSI is a module, it gets an unresolved symbol on req_finished_io. scsi_mod -> scsi_lib -> req_finished_io. Add EXPORT_SYMBOL(req_finished_io) in ll_rw_blk.c. Date: Tue Jan 9 15:24:29 PST 2001 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:81804a linux/drivers/block/ll_rw_blk.c - 1.59 From owner-linux-xfs@oss.sgi.com Tue Jan 9 20:28:59 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 20:28:49 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:12553 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 20:28:31 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0A4STe23292 for ; Tue, 9 Jan 2001 22:28:30 -0600 (CST) Message-ID: <3A5BE4E8.E736E35F@thebarn.com> Date: Tue, 09 Jan 2001 22:28:24 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: /dev permissions problem References: <3A5B9F57.23B46D92@sgi.com> <10101101228.ZM27003@wobbly.melbourne.sgi.com> <3A5BBDB9.21B404CD@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yup we have a small problem. Since I run devfs on most of the system I set up this hasn't cropped up before. It would appear the mode is never being set. brw-r--r-- 1 root root 8, 1 Jan 10 04:19 sdb [root@localhost /tmp2]# ls -i 8668138 foo 21223722 null 8668139 sdb [root@localhost /tmp2]# xfs_db -r /dev/sda5 xfs_db: inode 21223722 xfs_db: p core.magic = 0x494e core.mode = 0 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 0 core.uid = 0 core.gid = 0 core.atime.sec = Wed Jan 10 04:02:01 2001 core.atime.nsec = 057426000 core.mtime.sec = Wed Jan 10 04:02:01 2001 core.mtime.nsec = 057426000 core.ctime.sec = Wed Jan 10 04:02:01 2001 core.ctime.nsec = 057426000 core.size = 0 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 = 34 next_unlinked = null u = (empty) xfs_db: xfs_db: inode 8668139 xfs_db: p core.magic = 0x494e core.mode = 0 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 0 core.uid = 0 core.gid = 0 core.atime.sec = Sun Jan 7 20:35:29 2001 core.atime.nsec = 484237000 core.mtime.sec = Sun Jan 7 20:35:18 2001 core.mtime.nsec = 474237000 core.ctime.sec = Sun Jan 7 20:35:35 2001 core.ctime.nsec = 624237000 core.size = 17 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 = 10 next_unlinked = null u = (empty) Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 9 20:36:29 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 20:36:19 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43568 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 20:35:57 -0800 Received: from eric2.austin.sgi.com (root@eric2.austin.sgi.com [169.238.86.147]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02555 for ; Tue, 9 Jan 2001 20:44:42 -0800 (PST) mail_from (root@eric2.austin.sgi.com) Received: (from root@localhost) by eric2.austin.sgi.com (8.11.0/8.11.0) id f0A4cQV21244 for linux-xfs@oss.sgi.com; Tue, 9 Jan 2001 22:38:26 -0600 Date: Tue, 9 Jan 2001 22:38:26 -0600 From: root Message-Id: <200101100438.f0A4cQV21244@eric2.austin.sgi.com> Subject: TAKE - config file fixes, png updates To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 9 20:34:01 PST 2001 Workarea: eric2.austin.sgi.com:/home/eric/xfs/workarea-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81819a SOURCES/sgi.png - 1.1 - updated image for installer SOURCES/kernel-2.4.0-i386-BOOT.config - 1.20 SOURCES/kernel-2.4.0-i386-smp.config - 1.21 SOURCES/kernel-2.4.0-i386.config - 1.21 SOURCES/kernel-2.4.0-i586-smp.config - 1.21 SOURCES/kernel-2.4.0-i586.config - 1.22 SOURCES/kernel-2.4.0-i686-smp.config - 1.24 SOURCES/kernel-2.4.0-i686.config - 1.22 SOURCES/kernel-2.4.0-i686-enterprise.config - 1.10 - Turn off CONFIG_SMCTR for now - symbol problems SOURCES/anaconda_header.png - 1.2 - updated image for installer From owner-linux-xfs@oss.sgi.com Tue Jan 9 22:24:51 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 22:24:32 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58931 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 22:24:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA07759 for ; Tue, 9 Jan 2001 22:32:59 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA52329 for ; Wed, 10 Jan 2001 00:22:58 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f0A6LwQ05902 for linux-xfs@oss.sgi.com; Wed, 10 Jan 2001 00:21:58 -0600 Date: Wed, 10 Jan 2001 00:21:58 -0600 From: Russell Cattelan Message-Id: <200101100621.f0A6LwQ05902@gibble.americas.sgi.com> Subject: TAKE - Fix device file permission setting. To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 9 22:20:38 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:81822a linux/fs/xfs/linux/xfs_super.c - 1.106 - set i_op's in the case of a device file. This was preventing permission updates from making it out to disk. From owner-linux-xfs@oss.sgi.com Tue Jan 9 22:45:41 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 22:45:31 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39988 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 22:45:08 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA09546; Tue, 9 Jan 2001 22:53:53 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA39118; Tue, 9 Jan 2001 22:45:07 -0800 (PST) Date: Tue, 9 Jan 2001 22:45:07 -0800 (PST) Message-Id: <200101100645.WAA39118@info.engr.sgi.com> X-Pv-Incident: 812132 webPV: gibble.americas.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cattelan@engr.sgi.com) Subject: ISSU 812132 - Clean up un needed functions. To: ananth@engr.sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=812132 Submitter : cattelan Submitter Domain : engr Assigned Engineer : ananth Assigned Domain : engr Assigned Group : xfs-linux Category : software Customer Reported : F Priority : 4 Project : xfs-linux Status : open Description : These functions are no longer needed, part of a linux workaround. Core linux was fixed, and such these are no longer needed. int linvfs_write_full_page_sync( struct page *page) { return(linvfs_write_full_page(page, 1)); } int linvfs_write_full_page_async( struct page *page) { return(linvfs_write_full_page(page, 0)); } From owner-linux-xfs@oss.sgi.com Tue Jan 9 22:58:12 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 22:57:51 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:34313 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 22:57:24 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0A6vLe24703; Wed, 10 Jan 2001 00:57:21 -0600 (CST) Message-ID: <3A5C07CB.8309AC4A@thebarn.com> Date: Wed, 10 Jan 2001 00:57:15 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: Compiling 2.4.0 with "gcc-2.96" References: <4.3.2.7.2.20010109102406.035b4a70@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Mos wrote: Hmm all that I can say it probably has something to do with the do_div macros. xfs is using for 64 bit divides. What the error actually means? not sure. I would send a note to the gcc people see if the can shed some light on it. > Hi, > > If I try to compile the kernel with gcc-2.96-69 (the updated rpm for redhat > 7) it butts out in xfs_bmap.c > > This was just a test to checksee if it would compile at all. If someone is > capable of interpreting what this error means, if it could possibly be > fixed (for both compilers ofcourse) should it even be a bug. > > The kernel compiles fine using 2.91.66 ofcourse. I'm just trying to see > what a kernel would look like when compiled with "gcc-2.96" ;-) > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 > -fno-strict-aliasing -fomit-frame-pointer -pipe > -mpreferred-stack-boundary=2 -march=i686 -Wno-unused -Wno-parentheses > -Wno-uninitialized -I. -funsigned-char -Wno-unknown-pragmas -c -o > xfs_bmap.o xfs_bmap.c > xfs_bmap.c:543:36: warning: pasting would not give a valid preprocessing token > xfs_bmap.c:2830:36: warning: pasting would not give a valid preprocessing token > xfs_bmap.c: In function `xfs_bmap_del_extent': > xfs_bmap.c:3130: Unrecognizable insn: > (insn/i 254 252 4392 (parallel[ > (set (reg:SI 0 eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 266)) > (set (reg:SI 1 edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 266)) > (clobber (reg:QI 19 dirflag)) > (clobber (reg:QI 18 fpsr)) > (clobber (reg:QI 17 flags)) > ] ) -1 (nil) > (nil)) > xfs_bmap.c:3130: confused by earlier errors, bailing out > make[3]: *** [xfs_bmap.o] Error 2 > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > make[1]: *** [_subdir_xfs] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' > make: *** [_dir_fs] Error 2 > > Bye > > -- > Seth > Has anybody seen my lightbulb? > I _really_ need some light here. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Wed Jan 10 06:15:13 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 06:15:03 -0800 Received: from mailbox.samford.edu ([199.20.16.9]:64248 "EHLO mailbox.samford.edu") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 06:14:44 -0800 Received: from jmdanner.samford.edu (jmdanner.samford.edu [199.20.16.38]) by mailbox.samford.edu (2.1.3/8.9.1/Execmail 2.1) with ESMTP id IAA29896 for ; Wed, 10 Jan 2001 08:13:11 -0600 From: Mearl Danner Date: Wed, 10 Jan 2001 08:14:12 -0600 To: linux-xfs@oss.sgi.com Subject: Re: Compiling 2.4.0 with "gcc-2.96" In-Reply-To: <3A5C07CB.8309AC4A@thebarn.com> References: <3A5C07CB.8309AC4A@thebarn.com> <4.3.2.7.2.20010109102406.035b4a70@pop.xs4all.nl> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I've seen lots of discussion on the reiserfs list about "gcc-2.96". It appears to be Red-Hat specific and should be avoided when compiling a stock kernel. I believe Red-Hat put kgcc (using SuSE so can't confirm) on for compatibility reasons. gcc-2.95.2 is the latest on gnu.org's ftp site. 2.4.0 test kernels would compile with it. I haven't tried the 2.4 yet. On Wed, 10 Jan 2001 00:57:15 -0600 Russell Cattelan wrote: > Seth Mos wrote: > > Hmm all that I can say > it probably has something to do with the do_div macros. xfs is using for 64 bit > divides. > > What the error actually means? not sure. > > I would send a note to the gcc people see if the can shed some light on it. > > > > Hi, > > > > If I try to compile the kernel with gcc-2.96-69 (the updated rpm for redhat > > 7) it butts out in xfs_bmap.c > > > > This was just a test to checksee if it would compile at all. If someone is > > capable of interpreting what this error means, if it could possibly be > > fixed (for both compilers ofcourse) should it even be a bug. > > > > The kernel compiles fine using 2.91.66 ofcourse. I'm just trying to see > > what a kernel would look like when compiled with "gcc-2.96" ;-) > > > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 > > -fno-strict-aliasing -fomit-frame-pointer -pipe > > -mpreferred-stack-boundary=2 -march=i686 -Wno-unused -Wno-parentheses > > -Wno-uninitialized -I. -funsigned-char -Wno-unknown-pragmas -c -o > > xfs_bmap.o xfs_bmap.c > > xfs_bmap.c:543:36: warning: pasting would not give a valid preprocessing token > > xfs_bmap.c:2830:36: warning: pasting would not give a valid preprocessing token > > xfs_bmap.c: In function `xfs_bmap_del_extent': > > xfs_bmap.c:3130: Unrecognizable insn: > > (insn/i 254 252 4392 (parallel[ > > (set (reg:SI 0 eax) > > (asm_operands ("") ("=a") 0[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 266)) > > (set (reg:SI 1 edx) > > (asm_operands ("") ("=d") 1[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 266)) > > (clobber (reg:QI 19 dirflag)) > > (clobber (reg:QI 18 fpsr)) > > (clobber (reg:QI 17 flags)) > > ] ) -1 (nil) > > (nil)) > > xfs_bmap.c:3130: confused by earlier errors, bailing out > > make[3]: *** [xfs_bmap.o] Error 2 > > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > > make[2]: *** [first_rule] Error 2 > > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' > > make[1]: *** [_subdir_xfs] Error 2 > > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' > > make: *** [_dir_fs] Error 2 > > > > Bye > > > > -- > > Seth > > Has anybody seen my lightbulb? > > I _really_ need some light here. > > -- > Russell Cattelan > cattelan@thebarn.com > > > ----------------------------------------- Mearl Danner Data Communications/Network Specialist Email: jmdanner@samford.edu Samford University From owner-linux-xfs@oss.sgi.com Wed Jan 10 08:12:24 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 08:12:04 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56657 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 08:11:52 -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 IAA08465 for ; Wed, 10 Jan 2001 08:20:37 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA411815; Wed, 10 Jan 2001 10:10:22 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA23842; Wed, 10 Jan 2001 10:10:22 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client-1.7) via ESMTP id KAA14713; Wed, 10 Jan 2001 10:10:32 -0600 Message-Id: <200101101610.KAA14713@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mearl Danner cc: linux-xfs@oss.sgi.com Subject: Re: Compiling 2.4.0 with "gcc-2.96" In-Reply-To: Message from Mearl Danner of "Wed, 10 Jan 2001 08:14:12 CST." Date: Wed, 10 Jan 2001 10:10:32 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > I've seen lots of discussion on the reiserfs list about "gcc-2.96". It appear > s > to be Red-Hat specific and should be avoided when compiling a stock kernel. I > > believe Red-Hat put kgcc (using SuSE so can't confirm) on for compatibility > reasons. gcc-2.95.2 is the latest on gnu.org's ftp site. 2.4.0 test kernels > would compile with it. I haven't tried the 2.4 yet. > I think you will find that 2.95.2 exhibits similar problems with XFS - there was also a bug in the code generated for XFS which stopped it from working. Since the rest of the kernel compiles with the newer compilers now, XFS should probably do so too. Steve p.s. Just in case people did not notice the email address - I am back at SGI again. From owner-linux-xfs@oss.sgi.com Wed Jan 10 11:33:05 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 11:32:45 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:41736 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 11:32:24 -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 LAA22856 for ; Wed, 10 Jan 2001 11:31:30 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA417108 for ; Wed, 10 Jan 2001 13:31:07 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA82572 for ; Wed, 10 Jan 2001 13:31:07 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.7) id NAA07239; Wed, 10 Jan 2001 13:31:16 -0600 Message-Id: <200101101931.NAA07239@jen.americas.sgi.com> Date: Wed, 10 Jan 2001 13:31:16 -0600 Subject: TAKE - minor code cleanup To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I think we used this function in XFS once, we no longer do so remove it Date: Wed Jan 10 11:30:30 PST 2001 Workarea: 128.162.184.86:/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:81863a linux/include/asm-i386/atomic.h - 1.9 - Remove i386 version of atomic_add_return - it is not used and is not present in 2.4 From owner-linux-xfs@oss.sgi.com Wed Jan 10 12:32:44 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 12:32:34 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29294 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 12:32:18 -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 MAA06046 for ; Wed, 10 Jan 2001 12:41:04 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA417839 for ; Wed, 10 Jan 2001 14:31:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA35337 for ; Wed, 10 Jan 2001 14:31:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.9.3/SGI-client-1.7) id OAA07424; Wed, 10 Jan 2001 14:31:10 -0600 Message-Id: <200101102031.OAA07424@jen.americas.sgi.com> Date: Wed, 10 Jan 2001 14:31:10 -0600 Subject: TAKE - do not use inline ifdef XFS_DELALLOC To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This was a hangover from the development process Date: Wed Jan 10 12:30:24 PST 2001 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:81868a linux/mm/vmscan.c - 1.44 linux/mm/filemap.c - 1.63 - Don't conditionally define delalloc page code linux/include/linux/mm.h - 1.44 - Remove XFS_DELALLOC define linux/fs/buffer.c - 1.51 - Don't conditionally define delalloc page code From owner-linux-xfs@oss.sgi.com Wed Jan 10 22:37:38 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 22:37:18 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7714 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 22:36:48 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01595 for ; Wed, 10 Jan 2001 22:45:34 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA46221 for ; Wed, 10 Jan 2001 22:31:38 -0800 (PST) Message-ID: <3A5D541B.1F603165@sgi.com> Date: Wed, 10 Jan 2001 22:35:07 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: test2 CD & IDE drives Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing We are seeing some problems, likely related to 2.4.0. When creating an xfs root on an IDE drive with the test2 CD the installed kernel (2.4.0+xfs) does not get past mounting root. The system keeps spewing messages like "hda lost interrupt". The same system doesn't have problems with the same drive when running the boot kernel based on test11. A further datapoint is that if the root is made from ext2 the problem is not seen. Has anyone successfully installed the test2 CD on an IDE drive? I've also seen some reports relating to IDE & interrupts on the l-k mailing list, but couldn't really say distill any concise workaround for this problem. Does anyone have a good handle on what's going on? Please let me know if you need additional information. thanks! -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jan 10 22:57:08 2001 Received: by oss.sgi.com id ; Wed, 10 Jan 2001 22:56:48 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13354 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 10 Jan 2001 22:56:41 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA15572 for ; Wed, 10 Jan 2001 22:55:48 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0B6s8v29282; Thu, 11 Jan 2001 00:54:08 -0600 Message-ID: <3A5D5890.99303447@thebarn.com> Date: Thu, 11 Jan 2001 00:54:08 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Rajagopal Ananthanarayanan CC: linux-xfs@oss.sgi.com Subject: Re: test2 CD & IDE drives References: <3A5D541B.1F603165@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Rajagopal Ananthanarayanan wrote: > We are seeing some problems, likely related to 2.4.0. > When creating an xfs root on an IDE drive with the > test2 CD the installed kernel (2.4.0+xfs) does not > get past mounting root. The system keeps spewing > messages like "hda lost interrupt". The same system > doesn't have problems with the same drive when running > the boot kernel based on test11. A further datapoint is > that if the root is made from ext2 the problem is not seen. > > Has anyone successfully installed the test2 CD on an IDE drive? > I've also seen some reports relating to IDE & interrupts > on the l-k mailing list, but couldn't really say distill > any concise workaround for this problem. Does anyone have > a good handle on what's going on? Please let me know if you > need additional information. > > thanks! Does XFS work at all on the ide drive with a 2.4.0 kernel? ie ext2 root but xfs / ? BTW I just about have the latest build stuff done. I hand modified the test11 patch to add in the device perm fix, so the /dev/* it currently correct after reboot. I have all but the 686 install rpms built, should be done by morning. These kernels have devfs turned on by default. > > -------------------------------------------------------------------------- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------------------- -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Thu Jan 11 01:00:58 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 01:00:39 -0800 Received: from dep.biol.rug.nl ([129.125.143.1]:29199 "EHLO dep.biol.rug.nl") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 01:00:10 -0800 Received: from biol.rug.nl (imenz05.biol.rug.nl [129.125.132.245]) by dep.biol.rug.nl (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA15873; Thu, 11 Jan 2001 10:00:00 +0100 X-Authentication-Warning: dep.biol.rug.nl: Host imenz05.biol.rug.nl [129.125.132.245] claimed to be biol.rug.nl Message-ID: <3A5D7610.B5466A53@biol.rug.nl> Date: Thu, 11 Jan 2001 10:00:00 +0100 From: Aldert Zomer X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: test2 CD & IDE drives References: <3A5D541B.1F603165@sgi.com> <3A5D5890.99303447@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > > Does XFS work at all on the ide drive with a 2.4.0 kernel? > ie ext2 root but xfs / ? I've build the linux-2.4.0-XFS kernel and the tools etc. from cvs source on a redhat 7.0 box. I created an XFS partition on an IDE drive and mounted it. My / is still ext2. Works like a charm. The only problem is that my kernel modules won't load correctly with this kernel (Unresolved symbols in all of the modules) but this could also be some screw up of me. -- Ing. Aldert Zomer, | Tel: +31 50 36 32 360 Research Technician, | Fax: +31 50 36 35 205 IMEnz Bioengineering, | Email: zomeral@biol.rug.nl PO BOX 14, 9750 AA Haren, Netherlands | Homepage: http://www.imenz.com ------------------------------------------------------------------------ Automated Medline search: http://molgen.biol.rug.nl/cgi-bin/biomail/users.pl From owner-linux-xfs@oss.sgi.com Thu Jan 11 06:41:00 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 06:40:50 -0800 Received: from mail15.jump.net ([206.196.91.15]:44789 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 06:40:28 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f0BEePt04203; Thu, 11 Jan 2001 08:40:25 -0600 (CST) Message-ID: <3A5DC5DB.74632A6A@sgi.com> Date: Thu, 11 Jan 2001 08:40:27 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: Rajagopal Ananthanarayanan CC: linux-xfs@oss.sgi.com Subject: Re: test2 CD & IDE drives References: <3A5D541B.1F603165@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Looking through the kernel list, I see a couple things from Andre on this, early in the year... (thread starts at http://www.uwsg.iu.edu/hypermail/linux/kernel/0001.3/0940.html) One, he says that mixing Maxtor and WD drives on a bus causes timing problems(?!) So... just out of curiosity, what drives are in the box? Also, Andre says to the guy on the list: "Also you have not enable PIIX tuning." CONFIG_PIIX_TUNING is not set in the .configs in our tree, although CONFIG_BLK_DEV_PIIX is set. Config.help for CONFIG_BLK_DEV_PIIX says "If you say Y here, you should also say Y to 'PIIXn Tuning support,' below." so that looks like an error on our part. What's the version string on the test11 kernel that works? In some of the boot kernels we produced, both of the above options were NOT set on the BOOT kernel. I'll generate some new RPMs with both of the above set - is the box in good enough shape to try a new RPM? -Eric Rajagopal Ananthanarayanan wrote: > > We are seeing some problems, likely related to 2.4.0. > When creating an xfs root on an IDE drive with the > test2 CD the installed kernel (2.4.0+xfs) does not > get past mounting root. The system keeps spewing > messages like "hda lost interrupt". The same system > doesn't have problems with the same drive when running > the boot kernel based on test11. A further datapoint is > that if the root is made from ext2 the problem is not seen. > > Has anyone successfully installed the test2 CD on an IDE drive? > I've also seen some reports relating to IDE & interrupts > on the l-k mailing list, but couldn't really say distill > any concise workaround for this problem. Does anyone have > a good handle on what's going on? Please let me know if you > need additional information. > > thanks! From owner-linux-xfs@oss.sgi.com Thu Jan 11 07:23:21 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 07:23:02 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11841 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 07:22:39 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02371; Thu, 11 Jan 2001 07:31:25 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id HAA18853; Thu, 11 Jan 2001 07:22:38 -0800 (PST) Date: Thu, 11 Jan 2001 07:22:38 -0800 (PST) Message-Id: <200101111522.HAA18853@info.engr.sgi.com> X-Pv-Incident: 812132 webPV: jen.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (lord@sgi.com) Subject: REASSIGN 812132 - Clean up un needed functions. To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=812132 Status : open Priority : 4 *Assigned Engineer : lord *Assigned Domain : sgi.com Submitter : cattelan Project : xfs-linux Assigned Group : xfs-linux Opened Date : 01/09/01 *Modified User : lord *Modified User Domain : sgi.com *Description : These functions are no longer needed, part of a linux workaround. Core linux was fixed, and such these are no longer needed. int linvfs_write_full_page_sync( struct page *page) { ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Jan 11 2001 07:22:37AM ========================== I have been running with code for this..... From owner-linux-xfs@oss.sgi.com Thu Jan 11 08:20:51 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 08:20:42 -0800 Received: from btbntsys2.yucom.be ([212.8.180.2]:16658 "EHLO btbntsys2") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 08:20:27 -0800 Received: from mail pickup service by btbntsys2 with Microsoft SMTPSVC; Thu, 11 Jan 2001 17:01:05 +0100 Received: from oss.sgi.com ([216.32.174.190]) by 212.8.180.2 with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 11 Jan 2001 15:40:36 +0100 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 06:40:50 -0800 Received: from mail15.jump.net ([206.196.91.15]:44789 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 06:40:28 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f0BEePt04203; Thu, 11 Jan 2001 08:40:25 -0600 (CST) Message-ID: <3A5DC5DB.74632A6A@sgi.com> Date: Thu, 11 Jan 2001 08:40:27 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: Rajagopal Ananthanarayanan CC: linux-xfs@oss.sgi.com Subject: Re: test2 CD & IDE drives References: <3A5D541B.1F603165@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Looking through the kernel list, I see a couple things from Andre on this, early in the year... (thread starts at http://www.uwsg.iu.edu/hypermail/linux/kernel/0001.3/0940.html) One, he says that mixing Maxtor and WD drives on a bus causes timing problems(?!) So... just out of curiosity, what drives are in the box? Also, Andre says to the guy on the list: "Also you have not enable PIIX tuning." CONFIG_PIIX_TUNING is not set in the .configs in our tree, although CONFIG_BLK_DEV_PIIX is set. Config.help for CONFIG_BLK_DEV_PIIX says "If you say Y here, you should also say Y to 'PIIXn Tuning support,' below." so that looks like an error on our part. What's the version string on the test11 kernel that works? In some of the boot kernels we produced, both of the above options were NOT set on the BOOT kernel. I'll generate some new RPMs with both of the above set - is the box in good enough shape to try a new RPM? -Eric Rajagopal Ananthanarayanan wrote: > > We are seeing some problems, likely related to 2.4.0. > When creating an xfs root on an IDE drive with the > test2 CD the installed kernel (2.4.0+xfs) does not > get past mounting root. The system keeps spewing > messages like "hda lost interrupt". The same system > doesn't have problems with the same drive when running > the boot kernel based on test11. A further datapoint is > that if the root is made from ext2 the problem is not seen. > > Has anyone successfully installed the test2 CD on an IDE drive? > I've also seen some reports relating to IDE & interrupts > on the l-k mailing list, but couldn't really say distill > any concise workaround for this problem. Does anyone have > a good handle on what's going on? Please let me know if you > need additional information. > > thanks! From owner-linux-xfs@oss.sgi.com Thu Jan 11 08:35:12 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 08:35:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:19541 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 08:34:33 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25036 for ; Thu, 11 Jan 2001 08:33:40 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA46822; Thu, 11 Jan 2001 08:28:58 -0800 (PST) Message-ID: <3A5DE01A.CCCA2980@sgi.com> Date: Thu, 11 Jan 2001 08:32:26 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: test2 CD & IDE drives References: <3A5D541B.1F603165@sgi.com> <3A5D5890.99303447@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Does XFS work at all on the ide drive with a 2.4.0 kernel? > ie ext2 root but xfs / ? > Yes, with /boot & / as ext2, and another partition as XFS test2CD works fine. If /boot is ext2 & / is xfs the "hda interrupt lost" problem shows up. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jan 11 12:32:03 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 12:31:44 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:19480 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 12:31:25 -0800 Received: from feature.engr.sgi.com ([130.62.42.134]) 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 MAA09553; Thu, 11 Jan 2001 12:31:22 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA23165; Thu, 11 Jan 2001 12:30:03 -0800 (PST) Date: Thu, 11 Jan 2001 12:30:03 -0800 (PST) Message-Id: <200101112030.MAA23165@feature.engr.sgi.com> X-Pv-Incident: 812132 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (lord@sgi.com) Subject: TAKE 812132 - Clean up un needed functions. To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : cattelan *Status : closed Assigned Engineer : lord *Fixed By : lord *Fixed By Domain : sgi.com *Closed Date : 01/11/01 Priority : 4 *Modified Date : 01/11/01 *Modified User : lord *Modified User Domain : sgi.com *Fix Description : From: steve lord (TAKE) Date: Jan 11 2001 12:30:03PM [pvnews version: 1.71] ---------------------------- Date: Thu Jan 11 12:25:36 PST 2001 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:82102a linux/include/linux/fs.h - 1.74 - Remove unneeded address space op added for xfs linux/fs/xfs/linux/xfs_iops.c - 1.86 - Remve unneeded address space op added for xfs Description : These functions are no longer needed, part of a linux workaround. Core linux was fixed, and such these are no longer needed. int linvfs_write_full_page_sync( struct page *page) { ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: lord@sgi.com (BugWorks) Date: Jan 11 2001 07:22:37AM ========================== I have been running with code for this..... From owner-linux-xfs@oss.sgi.com Thu Jan 11 16:19:53 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 16:19:34 -0800 Received: from mta23-acc.tin.it ([212.216.176.76]:44960 "EHLO fep23-svc.tin.it") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 16:19:23 -0800 Received: from kamikaze ([212.171.41.45]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010112001914.CGVM456.fep23-svc.tin.it@kamikaze> for ; Fri, 12 Jan 2001 01:19:14 +0100 Message-ID: <010101c07c2e$c7e2c000$2d29abd4@kamikaze> From: "Pino Z." To: References: <3A5D541B.1F603165@sgi.com> <3A5D5890.99303447@thebarn.com> <3A5DE01A.CCCA2980@sgi.com> Subject: Re: test2 CD & IDE drives Date: Fri, 12 Jan 2001 01:29:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ----- Original Message ----- From: "Rajagopal Ananthanarayanan" To: "Russell Cattelan" Cc: Sent: Thursday, January 11, 2001 5:32 PM Subject: Re: test2 CD & IDE drives > > > > > Does XFS work at all on the ide drive with a 2.4.0 kernel? > > ie ext2 root but xfs / ? > > > > Yes, with /boot & / as ext2, and another partition as XFS > test2CD works fine. If /boot is ext2 & / is xfs the > "hda interrupt lost" problem shows up. > > > -------------------------------------------------------------------------- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jan 11 16:31:23 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 16:31:04 -0800 Received: from mta23-acc.tin.it ([212.216.176.76]:5539 "EHLO fep23-svc.tin.it") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 16:30:58 -0800 Received: from kamikaze ([212.171.41.45]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010112003055.CHIX456.fep23-svc.tin.it@kamikaze> for ; Fri, 12 Jan 2001 01:30:55 +0100 Message-ID: <011f01c07c30$69798560$2d29abd4@kamikaze> From: "Pino Z." To: "XFS mailung list" Subject: Installed XFS ROOT withouth etx2 Date: Fri, 12 Jan 2001 01:41:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01C07C38.C95F9070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C07C38.C95F9070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Just posting this email to reply to the people that say it's not possible to install xfs on /. I actually did without the use of any etx2 partition ie /boot and / they all reside within the same xfs partition. The partition is fairly small, 4 gigs, and is the third partition on my hd /deb/hda3. The install cd is test2, i have been experiencing other problems during the install related to the version of some rpm packages which made the install pretty tricky... ie switched back to the console with ctrl+alt+F2, copied the package, umounted the cd, made the dir structure under source recopied the package onto that(with the name the install was expecting to find) pressed ok to the error prompt, back to console removed the package and extra dirs under source dir, remounted the cdrom, and so on. That had to be done for at least 3 packages if i am not wrong. sincerly, Giuseppe Zompatori ------=_NextPart_000_011C_01C07C38.C95F9070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Just posting this email to reply to the = people=20 that
say it's not possible to install xfs on = /.
I actually did without the use of any = etx2=20 partition
ie /boot and / they all reside within = the same=20 xfs
partition.
The partition is fairly small, 4 gigs, = and is the=20 third partition
on my hd /deb/hda3.
 
The install cd is test2, i have been = experiencing=20 other
problems during the install related to = the version=20 of some
rpm packages which made the install = pretty=20 tricky...
ie switched back to the console with = ctrl+alt+F2,=20 copied
the package, umounted the cd, made the dir structure under
source recopied the package onto = that(with the name=20 the install
was expecting to find) pressed ok to the error prompt, back
to console removed the package and = extra dirs under=20 source dir,
remounted the cdrom, and so = on.
That had to be done for at least 3 = packages if i am=20 not wrong.
 
sincerly,
 
Giuseppe = Zompatori
------=_NextPart_000_011C_01C07C38.C95F9070-- From owner-linux-xfs@oss.sgi.com Thu Jan 11 17:16:23 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 17:16:04 -0800 Received: from mta23-acc.tin.it ([212.216.176.76]:11434 "EHLO fep23-svc.tin.it") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 17:15:40 -0800 Received: from kamikaze ([212.171.41.45]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with SMTP id <20010112011532.CIII456.fep23-svc.tin.it@kamikaze> for ; Fri, 12 Jan 2001 02:15:32 +0100 Message-ID: <016d01c07c36$a524e270$2d29abd4@kamikaze> From: "Pino Z." To: "XFS mailung list" References: <011f01c07c30$69798560$2d29abd4@kamikaze> <3A5E534E.8299F7A5@sgi.com> Subject: Re: Installed XFS ROOT withouth etx2 Date: Fri, 12 Jan 2001 02:26:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Well i should have wrote down the packages, something that I haven't done :( The LP printer daemon, the usermode package, and the... i can't remember the third... I'll take a look at the install log later and post again more accurate reports, thing that I can't do now because my internet (pppoe) stopped working with 2.4 and I am forced to use anothe os to connect. Giuseppe Zompatori ----- Original Message ----- From: "Eric Sandeen" To: "Pino Z." Sent: Friday, January 12, 2001 1:43 AM Subject: Re: Installed XFS ROOT withouth etx2 > > "Pino Z." wrote: > > > > > That had to be done for at least 3 packages if i am not wrong. > > Which packages? > > Thanks, > > -ERic > From owner-linux-xfs@oss.sgi.com Fri Jan 12 04:33:56 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 04:33:46 -0800 Received: from mail.relex.ru ([213.24.247.153]:26894 "EHLO mail.relex.ru") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 04:33:32 -0800 Received: from tst31.relex.ru (tst31.relex.ru [213.24.247.61]) by mail.relex.ru (8.9.3/8.9.3) with ESMTP id PAA05172 for ; Fri, 12 Jan 2001 15:33:17 +0300 Received: (from zheka@localhost) by tst31.relex.ru (8.9.3/8.8.5) id PAA02772; Fri, 12 Jan 2001 15:33:28 +0300 To: linux-xfs@oss.sgi.com Subject: bug in dmapi ? From: Eugene Exarevsky Date: 12 Jan 2001 15:33:28 +0300 Message-ID: Lines: 38 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi! Here is some results of my playing with XFS DMAPI: 1. libdm can't be compiled without inserting #define _LOOSE_KERNEL_NAMES #include before #include Maybe, insert this lines into dmapi_kern.h ? 2. After non-priveleged user called dmapi function that calls dm_query_fsys_for_vector() (invisible read, for example), vector leaved initialized by dm_enosys() function until reboot. So even root will give ENOSYS. Possible solution is to not check for CAP_MKNOD when getting operations vector. xfs_dmapi.c:xfs_dm_fcntl() begin may looks like : dmfcntlp = (dm_fcntl_t *)arg; #ifdef __sgi if (!cap_able_cred(credp, CAP_DEVICE_MGT)) return(EPERM); #else if (dmfcntlp->dmfc_subfunc != DM_FCNTL_FSYSVECTOR && !capable(CAP_MKNOD)) return(EPERM); #endif Sorry for my English. -- E.Exarevsky From owner-linux-xfs@oss.sgi.com Fri Jan 12 08:07:18 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 08:07:08 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8782 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 08:07:02 -0800 Received: from clink-eth.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04055 for ; Fri, 12 Jan 2001 08:15:48 -0800 (PST) mail_from (roehrich@clink-eth.americas.sgi.com) Received: (from roehrich@localhost) by clink-eth.americas.sgi.com (SGI-8.9.3/8.9.3) id KAA50070 for linux-xfs@oss.sgi.com; Fri, 12 Jan 2001 10:06:03 -0600 (CST) Date: Fri, 12 Jan 2001 10:06:03 -0600 (CST) From: Dean Roehrich Message-Id: <200101121606.KAA50070@clink-eth.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi/libdm fixes Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing add a makefile for libdm, make dmapi accessible to privileged procs only. Date: Fri Jan 12 08:05:21 PST 2001 Workarea: clink-eth.americas.sgi.com:/data/clink/a/roehrich/2.4.x-xfsB SPRs closed: Severity: Minor Modtype: Bugfix Test Description: tested, with dmf Keywords: NONE Requested reviewer(s): The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82150a cmd/xfs/libdm/Makefile - 1.1 - new makefile linux/fs/xfs/dmapi/dmapi_sysent.c - 1.6 - check for CAP_MKNOD cmd/xfs/libdm/dm_handle.c - 1.6 - xfs_fs.h does not need uuid.h anymore cmd/xfs/libdm/linux/dmapi_lib.c - 1.8 - need ioctl.h From owner-linux-xfs@oss.sgi.com Fri Jan 12 08:08:37 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 08:08:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3132 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 08:08: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 IAA20399 for ; Fri, 12 Jan 2001 08:07:17 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA442327; Fri, 12 Jan 2001 10:06:52 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA13088; Fri, 12 Jan 2001 10:06:33 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA06448; Fri, 12 Jan 2001 10:06:54 -0600 (CST) Message-Id: <200101121606.KAA06448@slobber.americas.sgi.com> To: Eugene Exarevsky cc: linux-xfs@oss.sgi.com Subject: Re: bug in dmapi ? Date: Fri, 12 Jan 2001 10:06:54 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >From: Eugene Exarevsky >Hi! > >Here is some results of my playing with XFS DMAPI: > >1. libdm can't be compiled without inserting > >#define _LOOSE_KERNEL_NAMES >#include > >before > >#include > >maybe, insert this lines into dmapi_kern.h ? It's not clear why you are seeing this and I'm not. I'll get a proper Makefile checked in for libdm. In the meantime I've included a copy of it at the end of this note. >2. >After non-priveleged user called dmapi function that calls dm_query_fsys_for_v >ector() >(invisible read, for example), vector leaved initialized by dm_enosys() functi >on until reboot. >So even root will give ENOSYS. It looks like I broke compatibility with Irix. You shouldn't be able to get into dmapi without privilege. At the top of dmapi_ioctl() in dmapi_sysent.c there should be a check for CAP_MKNOD.* I'll get this stuff checked in. Dean * In the Overview section of the XDSM spec, last sentence of Scope and Purpose, "These interfaces are not intended for direct use by typical end-users or unprivileged processes." ------------ cmd/xfs/libdm/Makefile ---------- # # Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved. # # This program is free software; you can redistribute it and/or modify it # under the terms of version 2 of the GNU General Public License as # published by the Free Software Foundation. # # This program is distributed in the hope that it would be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # # Further, this software is distributed without any warranty that it is # free of the rightful claim of any third person regarding infringement # or the like. Any license provided herein, whether implied or # otherwise, applies only to this software file. Patent licenses, if # any, provided herein do not apply to combinations of this program with # other software, or any other product whatsoever. # # You should have received a copy of the GNU General Public License along # with this program; if not, write the Free Software Foundation, Inc., 59 # Temple Place - Suite 330, Boston MA 02111-1307, USA. # # Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, # Mountain View, CA 94043, or: # # http://www.sgi.com # # For further information regarding this notice, see: # # http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ # TOPDIR = .. include $(TOPDIR)/include/builddefs CFLAGS += -Ilinux STATICLIBTARGET = libdm.a LIBTARGET = libdm.so CFILES = \ dm_attr.c \ dm_bulkattr.c \ dm_config.c \ dm_dmattr.c \ dm_event.c \ dm_handle.c \ dm_handle2path.c \ dm_hole.c \ dm_mountinfo.c \ dm_rdwr.c \ dm_region.c \ dm_right.c \ dm_session.c \ linux/dmapi_lib.c default: $(LIBTARGET) $(STATICLIBTARGET) include $(BUILDRULES) install: default #$(INSTALL) -m 755 -d $(XFS_CMDS_LIB_DIR) #$(INSTALL) -m 755 $(STATICLIBTARGET) $(XFS_CMDS_LIB_DIR) From owner-linux-xfs@oss.sgi.com Fri Jan 12 12:25:20 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 12:25:10 -0800 Received: from mcomail01.maxtor.com ([134.6.76.15]:65037 "HELO mcomail01.maxtor.com") by oss.sgi.com with SMTP id ; Fri, 12 Jan 2001 12:24:55 -0800 Received: from 134.6.67.21 by mcomail01.maxtor.com (InterScan E-Mail VirusWall NT); Fri, 12 Jan 2001 13:19:37 -0700 (Mountain Standard Time) Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 13:24:31 -0700 Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C025370A0@mcaexc01.msj.maxtor.com> From: "Davida, Joe" To: "'linux-xfs@oss.sgi.com'" Subject: xfs block size Date: Fri, 12 Jan 2001 13:24:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Are there any plans to support 64K FS block sizes? How soon (ballpark date)? In what version of Linux (2.4, 2.5...etc)? Cheers, Joe From owner-linux-xfs@oss.sgi.com Fri Jan 12 15:59:31 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 15:59:21 -0800 Received: from mail.connex.com ([216.100.236.3]:32269 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 15:59:02 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 15:55:57 -0800 Message-ID: From: Scott Smyth To: "'linux-xfs@oss.sgi.com'" Subject: XFS 2.4.0 tree w/ LVM_0_9-patches: buffer_flush problem w/ raid5 Date: Fri, 12 Jan 2001 15:55:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi; Thanks in advance if anyone can shed any light on this. versions: XFS kernel 2.4.0 tree (last night) LVM-0.9 w/ software RAID patches util-linux-2.10r I updated my XFS tree to last nights version on kernel 2.4.0 and updated to all the most recent LVM kernel and user space tools for 0.9. When doing a mount, the resync daemon stops and will not continue until reboot, but the kernel does not oops anymore. More importantly (I think), during a umount, the following oops occurs (attached is the ksymoops output at the bottom of the oops). Prior to this point (test13-pre3 XFS tree), I would see a kernel oops when the raid5 resync daemon would stop as well. I am not seeing that with the current system. Interestingly, the lvcreate of my current system also causes the resync daemon to hang when issuing the lvcreate. I have passed this information on to Neil Brown and will do so to the LVM list. However, I was wondering about the the kernel oops from the umount: -----------oops and ksymoops run---------------------------------- Unable to handle kernel NULL pointer dereference at virtual address 00000020 Jan 12 14:18:13 linuxdev kernel: c01318b3 Jan 12 14:18:13 linuxdev kernel: *pde = 00000000 Jan 12 14:18:13 linuxdev kernel: Oops: 0000 Jan 12 14:18:13 linuxdev kernel: CPU: 0 Jan 12 14:18:13 linuxdev kernel: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jan 12 14:18:13 linuxdev kernel: EFLAGS: 00010102 Jan 12 14:18:13 linuxdev kernel: eax: 00000000 ebx: 00000000 ecx: 0000030f edx: c7e020c0 Jan 12 14:18:13 linuxdev kernel: esi: 00003a00 edi: 00000000 ebp: c1989f40 esp: c1989f20 Jan 12 14:18:13 linuxdev kernel: ds: 0018 es: 0018 ss: 0018 Jan 12 14:18:13 linuxdev kernel: Process umount (pid: 929, stackpage=c1989000) Jan 12 14:18:13 linuxdev kernel: Stack: 00003a00 c456ae00 00000000 c7e020c0 00000000 00000000 3a000000 00000000 Jan 12 14:18:14 linuxdev kernel: c1989f54 c0131a8c 00003a00 00000000 c2676dc0 c1989f70 c0136363 00003a00 Jan 12 14:18:14 linuxdev kernel: c456ae00 ffffffff c19ab2e0 c1989f90 c1989fac c01364cb c2676dc0 00000000 Jan 12 14:18:15 linuxdev kernel: Call Trace: [] [] [] [] [] Jan 12 14:18:16 linuxdev kernel: Code: 8b 58 20 83 3d d0 87 34 c0 00 74 63 66 83 7d fa 00 74 0a 0f >>EIP; c01318b3 <===== Trace; c0131a8c Trace; c0136363 Trace; c01364cb Trace; c0136502 Trace; c0108f63 Code; c01318b3 00000000 <_EIP>: Code; c01318b3 <===== 0: 8b 58 20 mov 0x20(%eax),%ebx <===== Code; c01318b6 3: 83 3d d0 87 34 c0 00 cmpl $0x0,0xc03487d0 Code; c01318bd a: 74 63 je 6f <_EIP+0x6f> c0131922 Code; c01318bf c: 66 83 7d fa 00 cmpw $0x0,0xfffffffa(%ebp) Code; c01318c4 11: 74 0a je 1d <_EIP+0x1d> c01318d0 Code; c01318c6 13: 0f 00 00 sldt (%eax) From owner-linux-xfs@oss.sgi.com Fri Jan 12 18:23:32 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 18:23:22 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:44661 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 18:23:18 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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; Fri, 12 Jan 2001 18:23:17 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA94406; Fri, 12 Jan 2001 20:22:01 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f0D2JOL09079; Fri, 12 Jan 2001 20:19:24 -0600 From: Russell Cattelan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.47916.69173.299913@gibble.americas.sgi.com> Date: Fri, 12 Jan 2001 20:19:24 -0600 (CST) To: linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com Subject: XFS Linux RH7.0 prerelease-test3-rc3 X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing What I hope to be the last of this round of RedHat installer modifications: ftp://oss.sgi.com/projects/xfs/download/RH7.0-XFS-test3.iso Several minor things have been fixed. The only fix to XFS the one involving the permission modifications to device files not "sticking" Devfs has been turned on in the kernel, and is now used by default. Eric completely reworked the anaconda modifications to support kickstart installs; not extensively tested. NOTE NOTE NOTE The RedHat discs that are now required for install are the labeled "respin" fc9c2c23b02d2a35b75845530db81743 7.0-i386-respin-disc1.iso 0e77615754f281363c231b2d4b1806bb 7.0-i386-respin-disc2.iso It is likely the more prevalent images will be the respin images and not the original images, therefore the rpm list has been generated against the rpm's contained in the respin CD. DO NOT USE the older iso's for installs! The install process will get stuck in a loop requesting rpm's that do not exist on the older CD's. A CD with all of RedHat's current 7.0 updates and the SGI kernels was put together but was dropped, due to the fact the number of CD swaps number about a dozen just for the base install. Also it is not our intent to duplicate RedHat efforts. RedHat already provides CD images that will do updates quite painlessly. What I do plan on providing is a script that will take our CD the RedHat disc1/disc2 and Update CD combine them together into a single directory that can be used for NFS installs. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Jan 12 18:26:12 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 18:26:02 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:45581 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 18:25:59 -0800 Received: from brick.kernel.dk ([195.249.94.204] helo=burns.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14HGO5-0005W1-00; Sat, 13 Jan 2001 03:25:49 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14HGO0-0006rk-00; Sat, 13 Jan 2001 03:25:44 +0100 Date: Sat, 13 Jan 2001 03:25:44 +0100 From: Jens Axboe To: Scott Smyth Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS 2.4.0 tree w/ LVM_0_9-patches: buffer_flush problem w/ raid5 Message-ID: <20010113032544.E22380@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from SSmyth@Connex.com on Fri, Jan 12, 2001 at 03:55:49PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Jan 12 2001, Scott Smyth wrote: > Unable to handle kernel NULL pointer dereference at virtual address 00000020 Sync buffers oopsing there most likely means that a bad bit flip has corrupted the buffer list. I would suspect hw problems in this case, you should run some memory tests as this is most likely where the problem is. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Fri Jan 12 19:47:33 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 19:47:23 -0800 Received: from mail.connex.com ([216.100.236.3]:3589 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 19:46:55 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 19:43:50 -0800 Message-ID: From: Scott Smyth To: 'Jens Axboe ' Cc: "'linux-xfs@oss.sgi.com '" Subject: RE: XFS 2.4.0 tree w/ LVM_0_9-patches: buffer_flush problem w/ ra id5 Date: Fri, 12 Jan 2001 19:43:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C07D13.066273E0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C07D13.066273E0 Content-Type: text/plain; charset="iso-8859-1" Hi; This does look suspicious, but it is reproducible for 3 systems with completely different boards, memory, and CPUs so I don't think it is memory in this case although it might be related to how memory is used in general. I should mention a little more about the hardware though: IDE disks raidtools-0.90-6 I will go put in some debug statements to see if I can flush out more things so to speak. I attached one of the other kernel oops but they are consistent and reproduceable. thanks for the suggestion though, Scott -----Original Message----- From: Jens Axboe To: Scott Smyth Cc: 'linux-xfs@oss.sgi.com' Sent: 1/12/01 6:25 PM Subject: Re: XFS 2.4.0 tree w/ LVM_0_9-patches: buffer_flush problem w/ raid5 On Fri, Jan 12 2001, Scott Smyth wrote: > Unable to handle kernel NULL pointer dereference at virtual address 00000020 Sync buffers oopsing there most likely means that a bad bit flip has corrupted the buffer list. I would suspect hw problems in this case, you should run some memory tests as this is most likely where the problem is. -- * Jens Axboe * SuSE Labs ------_=_NextPart_000_01C07D13.066273E0 Content-Type: application/octet-stream; name="raid5_xfs_umount_ksymoops.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="raid5_xfs_umount_ksymoops.txt" ksymoops 2.3.4 on i686 2.4.0-28con. Options used=0A= -V (default)=0A= -k /proc/ksyms (default)=0A= -l /proc/modules (default)=0A= -o /lib/modules/2.4.0-28con/ (default)=0A= -m /boot/System.map (specified)=0A= =0A= Jan 12 19:12:33 localhost kernel: Unable to handle kernel NULL pointer = dereference at virtual address 00000020 =0A= Jan 12 19:12:33 localhost kernel: c01318b3 =0A= Jan 12 19:12:33 localhost kernel: *pde =3D 00000000 =0A= Jan 12 19:12:33 localhost kernel: Oops: 0000 =0A= Jan 12 19:12:33 localhost kernel: CPU: 0 =0A= Jan 12 19:12:33 localhost kernel: EIP: 0010:[sync_buffers+51/464] = =0A= Jan 12 19:12:33 localhost kernel: EFLAGS: 00010106 =0A= Jan 12 19:12:33 localhost kernel: eax: 00000000 ebx: 00000000 ecx: = 000004ab edx: c3d11980 =0A= Jan 12 19:12:33 localhost kernel: esi: 00003a00 edi: 00000000 ebp: = c28c1f40 esp: c28c1f20 =0A= Jan 12 19:12:33 localhost kernel: ds: 0018 es: 0018 ss: 0018 =0A= Jan 12 19:12:33 localhost kernel: Process umount (pid: 623, = stackpage=3Dc28c1000) =0A= Jan 12 19:12:33 localhost kernel: Stack: 00003a00 c2263600 00000000 = c3d11980 00000000 00000000 3a000000 00000000 =0A= Jan 12 19:12:33 localhost kernel: c28c1f54 c0131a8c 00003a00 = 00000000 c21ca2a0 c28c1f70 c0136363 00003a00 =0A= Jan 12 19:12:33 localhost kernel: c2263600 ffffffff c3af9860 = c28c1f90 c28c1fac c01364cb c21ca2a0 00000000 =0A= Jan 12 19:12:33 localhost kernel: Call Trace: [fsync_dev+16/60] = [do_umount+279/448] [sys_umount+191/232] [sys_oldumount+14/20] = [system_call+51/56] =0A= Jan 12 19:12:34 localhost kernel: Code: 8b 58 20 83 3d d0 87 34 c0 00 = 74 63 66 83 7d fa 00 74 0a 0f =0A= Using defaults from ksymoops -t elf32-i386 -a i386=0A= =0A= Code; 00000000 Before first symbol=0A= 00000000 <_EIP>:=0A= Code; 00000000 Before first symbol=0A= 0: 8b 58 20 mov 0x20(%eax),%ebx=0A= Code; 00000003 Before first symbol=0A= 3: 83 3d d0 87 34 c0 00 cmpl $0x0,0xc03487d0=0A= Code; 0000000a Before first symbol=0A= a: 74 63 je 6f <_EIP+0x6f> 0000006f Before = first symbol=0A= Code; 0000000c Before first symbol=0A= c: 66 83 7d fa 00 cmpw $0x0,0xfffffffa(%ebp)=0A= Code; 00000011 Before first symbol=0A= 11: 74 0a je 1d <_EIP+0x1d> 0000001d Before = first symbol=0A= Code; 00000013 Before first symbol=0A= 13: 0f 00 00 sldt (%eax)=0A= =0A= ------_=_NextPart_000_01C07D13.066273E0-- From owner-linux-xfs@oss.sgi.com Fri Jan 12 22:56:42 2001 Received: by oss.sgi.com id ; Fri, 12 Jan 2001 22:56:32 -0800 Received: from mail11.jump.net ([206.196.91.11]:43662 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Fri, 12 Jan 2001 22:56:22 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0D6uLw19380 for ; Sat, 13 Jan 2001 00:56:21 -0600 (CST) Message-ID: <3A5FFC1E.7A7166A5@sgi.com> Date: Sat, 13 Jan 2001 00:56:30 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS Linux RH7.0 prerelease-test3-rc3 References: <14943.47916.69173.299913@gibble.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell Cattelan wrote: > NOTE NOTE NOTE > The RedHat discs that are now required for install are the > labeled "respin" > fc9c2c23b02d2a35b75845530db81743 7.0-i386-respin-disc1.iso > 0e77615754f281363c231b2d4b1806bb 7.0-i386-respin-disc2.iso > > It is likely the more prevalent images will be the respin > images and not the original images, therefore the rpm list > has been generated against the rpm's contained in the respin CD. > > DO NOT USE the older iso's for installs! > The install process will get stuck in a loop requesting > rpm's that do not exist on the older CD's. To find out if you have an older ISO, look for these packages: up2date-2.0-4 usermode-1.35-2 LPRng-3.6.22-5 If you have an older ISO and you don't want to download another 650 megs to deal with it, you should be able to use your older discs by choosing "Select individual packages" during RPM selection, and then de-select these packages: System Environment / Base / up2date System Environment / Base / up2date-gnome System Environment / Daemons / LPRng Applications / System / usermode When the installer complains about dependencies, choose the third option, "Ignore package dependencies" The install should continue, and when your system is up and running, you should go back and install the above packages from the Red Hat updates. -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 13 16:14:19 2001 Received: by oss.sgi.com id ; Sat, 13 Jan 2001 16:14:09 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:15108 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Sat, 13 Jan 2001 16:13:51 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id BAA00984 for linux-xfs@oss.sgi.com; Sun, 14 Jan 2001 01:14:16 +0100 Date: Sun, 14 Jan 2001 01:14:16 +0100 From: sooo lame To: linux-xfs@oss.sgi.com Subject: #undef TCP_DEBUG Message-ID: <20010114011416.A732@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi. Wouldn't it be a good idea to undef TCP_DEBUG in include/tcp.h , it's only cosmetic change (unless you modify tcp code ;-) ) I don't want my logs to grow as fast as they do now... :) - Krzysztof From owner-linux-xfs@oss.sgi.com Sat Jan 13 20:27:32 2001 Received: by oss.sgi.com id ; Sat, 13 Jan 2001 20:27:23 -0800 Received: from mail11.jump.net ([206.196.91.11]:46019 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Sat, 13 Jan 2001 20:27:12 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0E4RBs13387 for ; Sat, 13 Jan 2001 22:27:11 -0600 (CST) Message-ID: <3A612A9D.E97A0778@sgi.com> Date: Sat, 13 Jan 2001 22:27:09 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: #undef TCP_DEBUG References: <20010114011416.A732@main.braxis.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing These are the only printks that get turned on w/ TCP_DEBUG, all seemingly related to bad things happening: printk(KERN_DEBUG "TCP: peer %u.%u.%u.%u:%u/%u shrinks window %u:%u:%u. Bad, what else can I say?\n", printk("BUG: retransmit in tcp_data_queue: seq %X\n", TCP_SKB_CB(skb)->seq); printk(KERN_DEBUG "*** tcp.c:tcp_data bug acked < copied\n") printk(KERN_DEBUG "reset_xmit_timer sk=%p %d when=0x%lx, caller=%p\n", printk("TCP: double destroy sk=%p\n", sk); If those are filling up your logs, I'd say there's a bigger problem to solve than a #define. :) -Eric sooo lame wrote: > > Hi. > > Wouldn't it be a good idea to undef TCP_DEBUG in include/tcp.h , > it's only cosmetic change (unless you modify tcp code ;-) ) > > I don't want my logs to grow as fast as they do now... :) > > - Krzysztof From owner-linux-xfs@oss.sgi.com Sat Jan 13 20:58:02 2001 Received: by oss.sgi.com id ; Sat, 13 Jan 2001 20:57:52 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:10599 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sat, 13 Jan 2001 20:57:41 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA09801 for ; Sat, 13 Jan 2001 20:57:13 -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 PAA06782; Sun, 14 Jan 2001 15:55:57 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA37217; Sun, 14 Jan 2001 15:55:56 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101141555.ZM37111@wobbly.melbourne.sgi.com> Date: Sun, 14 Jan 2001 15:55:55 -0400 In-Reply-To: Eric Sandeen "Re: #undef TCP_DEBUG" (Jan 13, 10:27pm) References: <20010114011416.A732@main.braxis.co.uk> <3A612A9D.E97A0778@sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: #undef TCP_DEBUG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Jan 13, 10:27pm, Eric Sandeen wrote: > Subject: Re: #undef TCP_DEBUG > These are the only printks that get turned on w/ TCP_DEBUG, all > seemingly related to bad things happening: > > printk(KERN_DEBUG "TCP: peer %u.%u.%u.%u:%u/%u shrinks window %u:%u:%u. > Bad, what else can I say?\n", > printk("BUG: retransmit in tcp_data_queue: seq %X\n", > TCP_SKB_CB(skb)->seq); > printk(KERN_DEBUG "*** tcp.c:tcp_data bug acked < copied\n") > printk(KERN_DEBUG "reset_xmit_timer sk=%p %d when=0x%lx, caller=%p\n", I'm guessing its this one -^ right? (was recently reported on lkml & the verdict there seemed to be that its harmless). > > > > Wouldn't it be a good idea to undef TCP_DEBUG in include/tcp.h , > > it's only cosmetic change (unless you modify tcp code ;-) ) > > include/net/tcp.h - fix is probably just to nuke line 21. i believe this is fixed since 2.4.0-ac3... not sure when we plan to move up from 2.4.0, but it'll likely be fixed when we do. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Jan 13 21:45:02 2001 Received: by oss.sgi.com id ; Sat, 13 Jan 2001 21:44:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2881 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 13 Jan 2001 21:44:40 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07538 for ; Sat, 13 Jan 2001 20:50:49 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA41983 for linux-xfs@oss.sgi.com; Sun, 14 Jan 2001 15:40:39 +1100 (EST) Date: Sun, 14 Jan 2001 15:40:39 +1100 (EST) From: Nathan Scott Message-Id: <200101140440.PAA41983@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor code/doc cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing reinstate last mod since no reason for backing it out has been forthcoming. also finish off documenting the config options (text added for pagebuf & dmapi). cheers. Modid: 2.4.x-xfs:slinx:82229a Date: Sat Jan 13 20:36:07 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/Documentation/Configure.help - 1.70 - add come verbage re pagebuf and dmapi config options. linux/fs/Config.in - 1.49 - remove "(incomplete)" quota tag. linux/fs/xfs/linux/Makefile - 1.37 - re-remove xfs_mount_opt.o, this function is trivial and (now) static. linux/fs/xfs/linux/xfs_linux.h - 1.41 - remove cruft resulting from having static function global. linux/fs/xfs/linux/xfs_super.c - 1.107 - put mount opt parsing code where it belongs. From owner-linux-xfs@oss.sgi.com Sun Jan 14 15:54:13 2001 Received: by oss.sgi.com id ; Sun, 14 Jan 2001 15:54:03 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:30770 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 14 Jan 2001 15:53:41 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA07798 for ; Sun, 14 Jan 2001 15:52:46 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA92780 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 10:52:19 +1100 (EST) Date: Mon, 15 Jan 2001 10:52:19 +1100 (EST) From: Nathan Scott Message-Id: <200101142352.KAA92780@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82233a Date: Sun Jan 14 15:51:57 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/Makefile - 1.39 - remove attr & libattr in preparation for extracting these into their own package. cmd/xfs/db/uuid.c - 1.8 cmd/xfs/dump/common/stkchk.c - 1.8 cmd/xfs/dump/restore/content.c - 1.19 cmd/xfs/logprint/xfs_log_recover.c - 1.8 linux/fs/xfs/xfs_log_recover.c - 1.199 - fix uninit'd variable warning. From owner-linux-xfs@oss.sgi.com Sun Jan 14 19:29:36 2001 Received: by oss.sgi.com id ; Sun, 14 Jan 2001 19:29:26 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64100 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 14 Jan 2001 19:29:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA01126 for ; Sun, 14 Jan 2001 19:37:52 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA61520 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 14:27:41 +1100 (EST) Date: Mon, 15 Jan 2001 14:27:41 +1100 (EST) From: Nathan Scott Message-Id: <200101150327.OAA61520@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Reworked build environment for the extended attributes library and command so that these are separated out from the base XFS user tools. This now builds into separate rpms (attr, attr-devel) using a similar method to the existing tools. There'll be a few similar structural changes to other parts of the user commands subtree to follow. cheers. Modid: 2.4.x-xfs:slinx:82237a Date: Sun Jan 14 19:18:30 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/attr/attr/Makefile - 1.2 cmd/attr/libattr/Makefile - 1.2 cmd/attr/Makefile - 1.1 cmd/attr/Makepkgs - 1.1 cmd/attr/README - 1.1 cmd/attr/VERSION - 1.1 cmd/attr/build/Makefile - 1.1 cmd/attr/build/rpm/Makefile - 1.1 cmd/attr/build/rpm/attr.spec.in - 1.1 cmd/attr/build/rpm/macros.template - 1.1 cmd/attr/build/rpm/rpm-2.rc.template - 1.1 cmd/attr/build/tar/Makefile - 1.1 cmd/attr/configure.in - 1.1 cmd/attr/doc/CHANGES - 1.1 cmd/attr/doc/COPYING - 1.1 cmd/attr/doc/INSTALL - 1.1 cmd/attr/doc/Makefile - 1.1 cmd/attr/doc/PORTING - 1.1 cmd/attr/include/Makefile - 1.1 cmd/attr/include/attributes.h - 1.1 cmd/attr/include/builddefs.in - 1.1 cmd/attr/include/buildrules - 1.1 cmd/attr/install-sh - 1.1 cmd/attr/man/Makefile - 1.1 cmd/attr/man/man1/Makefile - 1.1 cmd/attr/man/man1/attr.1 - 1.1 cmd/attr/man/man2/Makefile - 1.1 cmd/attr/man/man2/attrctl.2 - 1.1 cmd/attr/man/man3/Makefile - 1.1 cmd/attr/man/man3/attr_get.3 - 1.1 cmd/attr/man/man3/attr_list.3 - 1.1 cmd/attr/man/man3/attr_multi.3 - 1.1 cmd/attr/man/man3/attr_remove.3 - 1.1 cmd/attr/man/man3/attr_set.3 - 1.1 - initial version for reworked extended attributes build environment. From owner-linux-xfs@oss.sgi.com Sun Jan 14 20:06:16 2001 Received: by oss.sgi.com id ; Sun, 14 Jan 2001 20:06:06 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:12408 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 14 Jan 2001 20:05:59 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA03809 for ; Sun, 14 Jan 2001 20:04:14 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA00884 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 15:02:44 +1100 (EST) Date: Mon, 15 Jan 2001 15:02:44 +1100 (EST) From: Nathan Scott Message-Id: <200101150402.PAA00884@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82241a Date: Sun Jan 14 20:00:03 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfs/Makefile - 1.40 - move dump and other admin-type commands out and into their own package. From owner-linux-xfs@oss.sgi.com Sun Jan 14 20:42:16 2001 Received: by oss.sgi.com id ; Sun, 14 Jan 2001 20:42:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54375 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 14 Jan 2001 20:41:45 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07001 for ; Sun, 14 Jan 2001 20:50:35 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA65188 for ; Sun, 14 Jan 2001 20:41:13 -0800 (PST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA01589 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 15:39:18 +1100 (EST) Date: Mon, 15 Jan 2001 15:39:18 +1100 (EST) From: Nathan Scott Message-Id: <200101150439.PAA01589@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Reworked build environment for the administrative commands (dump, restore, fsr and friends). This package has a direct dependence on the extended attributes package (or will have once Andrew makes dump/restore aware of EAs again). Modid: 2.4.x-xfs:slinx:82249a Date: Sun Jan 14 20:35:39 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfsdump/Makepkgs - 1.1 cmd/xfsdump/README - 1.1 cmd/xfsdump/VERSION - 1.1 cmd/xfsdump/build/Makefile - 1.1 cmd/xfsdump/build/rpm/Makefile - 1.1 cmd/xfsdump/build/rpm/macros.template - 1.1 cmd/xfsdump/build/rpm/rpm-2.rc.template - 1.1 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.1 cmd/xfsdump/build/tar/Makefile - 1.1 cmd/xfsdump/configure.in - 1.1 cmd/xfsdump/debian/Makefile - 1.1 cmd/xfsdump/debian/changelog - 1.1 cmd/xfsdump/debian/control - 1.1 cmd/xfsdump/debian/copyright - 1.1 cmd/xfsdump/debian/rules - 1.1 cmd/xfsdump/doc/CHANGES - 1.1 cmd/xfsdump/doc/COPYING - 1.1 cmd/xfsdump/doc/INSTALL - 1.1 cmd/xfsdump/doc/Makefile - 1.1 cmd/xfsdump/doc/PORTING - 1.1 cmd/xfsdump/doc/README.xfsdump - 1.1 cmd/xfsdump/install-sh - 1.1 cmd/xfsdump/man/Makefile - 1.1 cmd/xfsdump/man/man8/Makefile - 1.1 cmd/xfsdump/man/man8/xfs_copy.8 - 1.1 cmd/xfsdump/man/man8/xfs_estimate.8 - 1.1 cmd/xfsdump/man/man8/xfs_fsr.8 - 1.1 cmd/xfsdump/man/man8/xfsdump.8 - 1.1 cmd/xfsdump/man/man8/xfsinvutil.8 - 1.1 cmd/xfsdump/man/man8/xfsrestore.8 - 1.1 - initial version for reworked xfsdump & co. build environment. From owner-linux-xfs@oss.sgi.com Mon Jan 15 09:07:44 2001 Received: by oss.sgi.com id ; Mon, 15 Jan 2001 09:07:34 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:47123 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 15 Jan 2001 09:07:30 -0800 Received: from info.engr.sgi.com ([192.26.80.216]) 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 JAA06710; Mon, 15 Jan 2001 09:06:09 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA22509; Mon, 15 Jan 2001 09:06:08 -0800 (PST) Date: Mon, 15 Jan 2001 09:06:08 -0800 (PST) Message-Id: <200101151706.JAA22509@info.engr.sgi.com> X-Pv-Incident: 811747 webPV: oldchicago.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@odin.corp.sgi.com (nb@sgi.com) Subject: REASSIGN 811747 - Report of XFS data corruption on hard system crash To: raa@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=811747 Status : open Priority : 2 *Assigned Engineer : raa Submitter : pj Project : xfs *Assigned Group : xfs-linux Opened Date : 01/04/01 *Modified User : nb *Modified User Domain : sgi.com *Description : A customer from an unknown user site sent email to devprogram@sgi.com, which resulted in an email thread with myself, pj@sgi.com, during which thread he reported the following xfs data corruption problem. I told him I would pass his report on to the xfs folks, but I didn't even hint that he would ever receive any follow-up. Do with the following as you like. If it doesn't help you make xfs a better product, then don't worry about this report. ..... ========================== ADDITIONAL INFORMATION (REASSIGN) From: nb@sgi.com (BugWorks) Date: Jan 15 2001 09:06:08AM ========================== From owner-linux-xfs@oss.sgi.com Mon Jan 15 18:18:39 2001 Received: by oss.sgi.com id ; Mon, 15 Jan 2001 18:18:29 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:33543 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 15 Jan 2001 18:18:14 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA02097 for ; Mon, 15 Jan 2001 16:31:04 -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 LAA19063; Tue, 16 Jan 2001 11:30:41 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA42102; Tue, 16 Jan 2001 11:30:40 +1100 (EDT) From: "Nathan Scott" Message-Id: <10101161130.ZM41995@wobbly.melbourne.sgi.com> Date: Tue, 16 Jan 2001 11:30:39 -0400 In-Reply-To: "Davida, Joe" "xfs block size" (Jan 12, 1:24pm) References: <09D1E9BD9C30D311919200A0C9DD5C2C025370A0@mcaexc01.msj.maxtor.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Davida, Joe" , "'linux-xfs@oss.sgi.com '" Subject: Re: xfs block size Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi Joe, On Jan 12, 1:24pm, Davida, Joe wrote: > Subject: xfs block size > Are there any plans to support 64K FS block > sizes? > How soon (ballpark date)? > In what version of Linux (2.4, 2.5...etc)? > Yes, there are plans - details are at: http://oss.sgi.com/projects/xfs/todos.html#_multiblocksize >From a conversation with Russell, he's predicted an eta of around 3 - 6 months from now (also saying that at the moment its not clear exactly what the solution will be and that there's plenty on his plate before getting onto this issue). We'd be looking at a 2.4.x+XFS tree I would imagine. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 15 20:13:19 2001 Received: by oss.sgi.com id ; Mon, 15 Jan 2001 20:12:59 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54351 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 15 Jan 2001 20:12:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA00381 for ; Mon, 15 Jan 2001 20:21:39 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA86989 for linux-xfs@oss.sgi.com; Tue, 16 Jan 2001 15:11:27 +1100 (EST) Date: Tue, 16 Jan 2001 15:11:27 +1100 (EST) From: Nathan Scott Message-Id: <200101160411.PAA86989@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82321a Date: Mon Jan 15 20:10:42 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfstests/configure.in - 1.1 cmd/xfstests/include/Makefile - 1.1 cmd/xfstests/include/builddefs.in - 1.1 cmd/xfstests/include/buildrules - 1.1 - finish off the tests restructuring. From owner-linux-xfs@oss.sgi.com Mon Jan 15 22:24:19 2001 Received: by oss.sgi.com id ; Mon, 15 Jan 2001 22:24:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:17493 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 15 Jan 2001 22:23:52 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA08606 for ; Mon, 15 Jan 2001 02:44:19 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA57109 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 21:43:54 +1100 (EST) Date: Mon, 15 Jan 2001 21:43:54 +1100 (EST) From: Timothy Shimmin Message-Id: <200101151043.VAA57109@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - XFS/ACLs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Adds XFS/ACL support. This includes much of the ACL/Connex patch based on slinx-xfs code and OB1 source - thanks muchly :) Nathan has reorganised the cmd/acl stuff. Hopefully, I haven't missed anything :) TODO: 1. - make the ACL stuff configurable like QUOTA and DMAPI - do this soon 2. - fix up the cred handling of the vop functions - allow cred from behavior, such as in CXFS case, to be used - different schemes to try: - will initially do method where when we need to use the cred we will test to see if it is NULL and if it is then use the Linux method to test the credential fields, otherwise we will actually use the given cred fields --Tim Modified files: (SYNC = header files to be kept in sync) Makefile - add acl stuff SYNC: cmd/xfsprogs/include/xfs_cred.h - add capable_cred function, add cred to mac proto SYNC: cmd/xfsprogs/include/xfs_inode.h - add cred parameter to xfs_iaccess cmd/xfstests/tools/fixcopyright - 2001 cmd/xfstests/tools/srcdiff - cross check acl.h file This needs to be updated for cmd/xfs change. linux/arch/i386/kernel/entry.S - add acl syscalls linux/fs/stat.c - adds sys_acl_get, sys_acl_set after sys_attrctl linux/fs/xfs/Makefile - add xfs_acl.o, xfs_attr_fetch.o linux/fs/xfs/linux/Makefile - get rid of stubs - fix up config later linux/fs/xfs/linux/xfs_aclstubs.c - trim & add cred parameter to acl_xfs_iaccessSYNC: linux/fs/xfs/linux/xfs_cred.h - capable_cred function, fix mac proto linux/fs/xfs/linux/xfs_globals.c - xfs_acl_enabled name change linux/fs/xfs/linux/xfs_iops.c - added: linvfs_acl_get, linvfs_acl_set defns linux/fs/xfs/linux/xfs_vnode.h added: vop_acl_get_t, vop_acl_set_t VOP_ACL_GET, VOP_ACL_SET linux/fs/xfs/macstubs.c - added: mac_xfs_vaccess stub linux/fs/xfs/xfs.h - fix for acl headers linux/fs/xfs/xfs_attr.c - add cred param for xfs_iaccess linux/fs/xfs/xfs_dfrag.c - add extra cred param for xfs_iaccess linux/fs/xfs/xfs_inode.c - add extra cred param for xfs_iaccess SYNC: linux/fs/xfs/xfs_inode.h - add extra cred param linux/fs/xfs/xfs_rename.c - add extra cred param for xfs_iaccess linux/fs/xfs/xfs_utils.c - add extra cred param for xfs_iaccess linux/fs/xfs/xfs_utils.h - add extra cred param linux/fs/xfs/xfs_vfsops.c - call xfs_acl_init linux/fs/xfs/xfs_vnodeops.c - add extra cred param linux/include/asm-i386/unistd.h - add acl syscall nums linux/include/linux/fs.h - add acl inode ops Modid: 2.4.x-xfs:slinx:82289a Date: Mon Jan 15 02:28:46 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs-acl Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Makefile - 1.33 cmd/xfsprogs/include/xfs_cred.h - 1.2 cmd/xfsprogs/include/xfs_inode.h - 1.2 cmd/xfstests/tools/fixcopyright - 1.2 cmd/xfstests/tools/srcdiff - 1.2 linux/arch/i386/kernel/entry.S - 1.31 linux/fs/stat.c - 1.16 linux/fs/xfs/Makefile - 1.114 linux/fs/xfs/linux/Makefile - 1.38 linux/fs/xfs/linux/xfs_aclstubs.c - 1.8 linux/fs/xfs/linux/xfs_cred.h - 1.9 linux/fs/xfs/linux/xfs_globals.c - 1.21 linux/fs/xfs/linux/xfs_iops.c - 1.87 linux/fs/xfs/linux/xfs_vnode.h - 1.11 linux/fs/xfs/macstubs.c - 1.7 linux/fs/xfs/xfs.h - 1.13 linux/fs/xfs/xfs_attr.c - 1.81 linux/fs/xfs/xfs_dfrag.c - 1.26 linux/fs/xfs/xfs_inode.c - 1.309 linux/fs/xfs/xfs_inode.h - 1.143 linux/fs/xfs/xfs_rename.c - 1.29 linux/fs/xfs/xfs_utils.c - 1.35 linux/fs/xfs/xfs_utils.h - 1.14 linux/fs/xfs/xfs_vfsops.c - 1.305 linux/fs/xfs/xfs_vnodeops.c - 1.484 linux/include/asm-i386/unistd.h - 1.14 linux/include/linux/fs.h - 1.75 cmd/acl/Makefile - 1.1 cmd/acl/Makepkgs - 1.1 cmd/acl/README - 1.1 cmd/acl/VERSION - 1.1 cmd/acl/build/Makefile - 1.1 cmd/acl/build/rpm/Makefile - 1.1 cmd/acl/build/rpm/acl.spec.in - 1.1 cmd/acl/build/rpm/macros.template - 1.1 cmd/acl/build/rpm/rpm-2.rc.template - 1.1 cmd/acl/build/tar/Makefile - 1.1 cmd/acl/chacl/Makefile - 1.1 cmd/acl/chacl/chacl.c - 1.1 cmd/acl/configure.in - 1.1 cmd/acl/debian/Makefile - 1.1 cmd/acl/debian/changelog - 1.1 cmd/acl/debian/control - 1.1 cmd/acl/debian/copyright - 1.1 cmd/acl/debian/rules - 1.1 cmd/acl/doc/CHANGES - 1.1 cmd/acl/doc/COPYING - 1.1 cmd/acl/doc/INSTALL - 1.1 cmd/acl/doc/Makefile - 1.1 cmd/acl/doc/PORTING - 1.1 cmd/acl/include/Makefile - 1.1 cmd/acl/include/acl.h - 1.1 cmd/acl/include/builddefs.in - 1.1 cmd/acl/include/buildrules - 1.1 cmd/acl/install-sh - 1.1 cmd/acl/libacl/Makefile - 1.1 cmd/acl/libacl/acl.c - 1.1 cmd/acl/man/Makefile - 1.1 cmd/acl/man/man1/Makefile - 1.1 cmd/acl/man/man1/chacl.1 - 1.1 cmd/acl/man/man2/Makefile - 1.1 cmd/acl/man/man2/acl_get.2 - 1.1 cmd/acl/man/man2/acl_set.2 - 1.1 cmd/acl/man/man3/Makefile - 1.1 cmd/acl/man/man3/acl_copy_ext.3 - 1.1 cmd/acl/man/man3/acl_delete_def_file.3 - 1.1 cmd/acl/man/man3/acl_dup.3 - 1.1 cmd/acl/man/man3/acl_free.3 - 1.1 cmd/acl/man/man3/acl_from_text.3 - 1.1 cmd/acl/man/man3/acl_get_fd.3 - 1.1 cmd/acl/man/man3/acl_get_file.3 - 1.1 cmd/acl/man/man3/acl_size.3 - 1.1 cmd/acl/man/man3/acl_valid.3 - 1.1 cmd/acl/man/man5/Makefile - 1.1 cmd/acl/man/man5/acl.5 - 1.1 linux/fs/xfs/xfs_acl.c - 1.1 linux/fs/xfs/xfs_acl.h - 1.1 linux/include/linux/acl.h - 1.1 From owner-linux-xfs@oss.sgi.com Tue Jan 16 01:53:20 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 01:53:01 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:62069 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 01:52:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA12371 for ; Sun, 14 Jan 2001 23:29:41 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA84121 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 18:29:14 +1100 (EST) Date: Mon, 15 Jan 2001 18:29:14 +1100 (EST) From: Nathan Scott Message-Id: <200101150729.SAA84121@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82288a Date: Sun Jan 14 23:29:08 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Makefile - 1.32 - rework ProPack build for new command packaging structure. From owner-linux-xfs@oss.sgi.com Tue Jan 16 02:02:30 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 02:02:21 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:53878 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 02:02:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA11278 for ; Sun, 14 Jan 2001 23:14:58 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA76558 for linux-xfs@oss.sgi.com; Mon, 15 Jan 2001 18:14:31 +1100 (EST) Date: Mon, 15 Jan 2001 18:14:31 +1100 (EST) From: Nathan Scott Message-Id: <200101150714.SAA76558@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This reworks the base commands package build. This is modelled quite a bit on the e2fsprogs build and rpm packaging - generates xfsprogs and xfsprogs-devel rpms. The xfsprogs and xfsdump packages conflict with the (now defunct) xfs-cmds package. The xfsprogs code is pretty much complete and ready for the 1st real XFS release. All experimental interfaces (unofficial extended attr & acl syscalls, etc) are separated out into their own packages now (they are not xfs-specific at all). NB: to build from source, there are now separate "make install" and "make install-dev" targets in all packages and note that some packages have dependencies on others (xfsdump requires attr and xfsprogs files to be built and installed, for example). The remaining things on my list are the dmapi package (discussing with Dean now) and the stress tests - I'll knock this off tomorrow. cheers. Modid: 2.4.x-xfs:slinx:82287a Date: Sun Jan 14 22:52:52 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfsprogs/bmap/Makefile - 1.2 cmd/xfsprogs/build/Makefile - 1.2 cmd/xfsprogs/build/rpm/Makefile - 1.2 cmd/xfsprogs/build/tar/Makefile - 1.2 cmd/xfsprogs/db/Makefile - 1.2 cmd/xfsprogs/db/input.c - 1.2 cmd/xfsprogs/doc/Makefile - 1.2 cmd/xfsprogs/fsck/Makefile - 1.2 cmd/xfsprogs/growfs/Makefile - 1.2 cmd/xfsprogs/include/Makefile - 1.2 cmd/xfsprogs/include/builddefs.in - 1.2 cmd/xfsprogs/include/buildrules - 1.2 cmd/xfsprogs/libhandle/Makefile - 1.2 cmd/xfsprogs/libxfs/Makefile - 1.2 cmd/xfsprogs/libxfs/xfs.h - 1.2 cmd/xfsprogs/logprint/Makefile - 1.2 cmd/xfsprogs/man/Makefile - 1.2 cmd/xfsprogs/man/man5/Makefile - 1.2 cmd/xfsprogs/man/man8/Makefile - 1.2 cmd/xfsprogs/mkfile/Makefile - 1.2 cmd/xfsprogs/mkfs/Makefile - 1.2 cmd/xfsprogs/repair/Makefile - 1.2 cmd/xfsprogs/repair/attr_repair.c - 1.2 cmd/xfsprogs/repair/attr_repair.h - 1.2 cmd/xfsprogs/Makefile - 1.1 cmd/xfsprogs/Makepkgs - 1.1 cmd/xfsprogs/README - 1.1 cmd/xfsprogs/VERSION - 1.1 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.1 cmd/xfsprogs/configure.in - 1.1 cmd/xfsprogs/doc/CHANGES - 1.1 cmd/xfsprogs/doc/COPYING - 1.1 cmd/xfsprogs/doc/CREDITS - 1.1 cmd/xfsprogs/doc/INSTALL - 1.1 cmd/xfsprogs/doc/PORTING - 1.1 cmd/xfsprogs/install-sh - 1.1 cmd/xfsprogs/man/man3/Makefile - 1.1 cmd/xfsprogs/man/man3/handle.3 - 1.1 - initial version for reworked xfsprogs build environment. From owner-linux-xfs@oss.sgi.com Tue Jan 16 13:51:09 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 13:50:49 -0800 Received: from mail.myrealbox.com ([192.108.102.201]:32182 "EHLO myrealbox.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 13:50:21 -0800 Received: from angelw2k [137.65.47.155] by myrealbox.com with Novonyx SMTP Server $Revision: 2.75 $; Tue, 16 Jan 2001 14:50:19 -0700 (MDT) Message-ID: <000801c08006$401e2390$9b2f4189@angelw2k> From: "Micah Gorrell" To: Subject: Does XFS work with release 2.4 kernel? Date: Tue, 16 Jan 2001 14:49:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C07FCB.9383A220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C07FCB.9383A220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am working on a project that would benifit a great deal from the XFS = file system, but we can not run it on the 2.4test5 kernel. Does XFS = work with the released 2.4 kernel? If so what is its current state. I = would like to recommend XFS to our customers but we can not do that if = it is not stable. Thanks. Micah ------=_NextPart_000_0005_01C07FCB.9383A220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am working on a project that would = benifit a=20 great deal from the XFS file system, but we can not run it on the = 2.4test5=20 kernel.  Does XFS work with the released 2.4 kernel?  If so = what is=20 its current state.  I would like to recommend XFS to our customers = but we=20 can not do that if it is not stable.  Thanks.
 
Micah
------=_NextPart_000_0005_01C07FCB.9383A220-- From owner-linux-xfs@oss.sgi.com Tue Jan 16 13:55:39 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 13:55:19 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:19321 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 13:55:05 -0800 Received: from nodin.corp.sgi.com ([198.29.75.193]) 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 NAB06098; Tue, 16 Jan 2001 13:55:01 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA31919; Tue, 16 Jan 2001 13:54:24 -0800 (PST) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA33165; Tue, 16 Jan 2001 13:54:23 -0800 (PST) Date: Tue, 16 Jan 2001 13:54:23 -0800 (PST) Message-Id: <200101162154.NAA33165@info.engr.sgi.com> X-Pv-Incident: 804570 webPV: fsgi056.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@odin.corp.sgi.com (steiner@sgi.com) Subject: CLOSE 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570 *Status : closed Priority : 3 Assigned Engineer : nb Submitter : coreym Opened Date : 10/11/00 *Closed Date : 01/16/01 *Fixed By : steiner *Fixed By Domain : sgi.com *Modified Date : 01/16/01 *Modified User : steiner *Modified User Domain : sgi.com *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: steiner@sgi.com (BugWorks) Date: Jan 16 2001 01:54:23PM ========================== This code was checked in to the 2.4.0-test12 tree. I thought I closed the PV but it appears I didnt...... From owner-linux-xfs@oss.sgi.com Tue Jan 16 14:04:19 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 14:04:09 -0800 Received: from perilith.com ([207.198.250.232]:13065 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Tue, 16 Jan 2001 14:03:57 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id 3DAE63E093; Tue, 16 Jan 2001 17:03:56 -0500 (EST) Date: Tue, 16 Jan 2001 14:03:56 -0800 From: Drew Bloechl To: Micah Gorrell Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS work with release 2.4 kernel? Message-ID: <20010116140356.A17662@perilith.com> References: <000801c08006$401e2390$9b2f4189@angelw2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <000801c08006$401e2390$9b2f4189@angelw2k>; from angelcode@myrealbox.com on Tue, Jan 16, 2001 at 02:49:49PM -0700 X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Jan 16, 2001 at 02:49:49PM -0700, Micah Gorrell wrote: > I am working on a project that would benifit a great deal from the XFS file system, but we can not run it on the 2.4test5 kernel. Does XFS work with the released 2.4 kernel? If so what is its current state. I would like to recommend XFS to our customers but we can not do that if it is not stable. Thanks. The current CVS tree is 2.4.0. -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Tue Jan 16 15:09:00 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 15:08:40 -0800 Received: from perilith.com ([207.198.250.232]:50441 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Tue, 16 Jan 2001 15:08:33 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id F1EB93E094; Tue, 16 Jan 2001 18:08:31 -0500 (EST) Date: Tue, 16 Jan 2001 15:08:31 -0800 From: Drew Bloechl To: linux-xfs@oss.sgi.com Subject: CVS oddity Message-ID: <20010116150831.B17662@perilith.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing When doing a cvs update I get this: ... cvs server: Updating fs/xfs cvs server: Updating fs/xfs/dmapi cvs server: Updating fs/xfs/linux cvs server: Updating fs/xfs/pseudo-inc cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/fs/xfs/pseudo-inc: No such file or directory cvs server: skipping directory fs/xfs/pseudo-inc cvs server: Updating fs/xfs/support ... -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Tue Jan 16 15:25:29 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 15:25:20 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58432 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 15:24:54 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07599; Tue, 16 Jan 2001 15:33:46 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA58459; Tue, 16 Jan 2001 15:24:23 -0800 (PST) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA86202; Tue, 16 Jan 2001 15:24:22 -0800 (PST) Date: Tue, 16 Jan 2001 15:24:22 -0800 (PST) Message-Id: <200101162324.PAA86202@info.engr.sgi.com> X-Pv-Incident: 804570 webPV: dhcp-163-154-5-223.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (srn@engr.sgi.com) Subject: REOPEN 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570 *Status : open Priority : 3 Assigned Engineer : nb Submitter : coreym Project : xfs-linux Assigned Group : xfs-linux Opened Date : 10/11/00 *Closed Date : *Fixed By : *Fixed By Domain : *Verified Date : *Modified User : srn *Modified User Domain : engr *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (REOPEN) From: srn@engr (BugWorks) Date: Jan 16 2001 03:24:20PM ========================== As Jack noted, the temp patch mentioned in this pv has been applied to the snia tree for now as a short term fix for QA SNIA testing. This bug should probably not have been closed since there's another more complete fix in the works according to anath and chait. --steve From owner-linux-xfs@oss.sgi.com Tue Jan 16 16:20:00 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 16:19:50 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3442 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 16:19:37 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA20712 for ; Tue, 16 Jan 2001 16:18:41 -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 LAA05445; Wed, 17 Jan 2001 11:18:18 +1100 (EDT) From: Timothy Shimmin Message-Id: <200101170018.LAA05445@boing.melbourne.sgi.com> Subject: Re: CVS oddity To: drew@cesspool.net (Drew Bloechl) Date: Wed, 17 Jan 2001 11:18:18 +1100 (EDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <20010116150831.B17662@perilith.com> from "Drew Bloechl" at Jan 16, 2001 03:08:31 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > When doing a cvs update I get this: > > ... > cvs server: Updating fs/xfs > cvs server: Updating fs/xfs/dmapi > cvs server: Updating fs/xfs/linux > cvs server: Updating fs/xfs/pseudo-inc > cvs server: cannot open directory > /cvs/linux-2.4-xfs/linux/fs/xfs/pseudo-inc: No such file or directory > cvs server: skipping directory fs/xfs/pseudo-inc I p_source_tree_remove'd (cmd from SGI's cvs equivalent) the last file in this directory, fs/xfs/pseudo-inc/sys/acl.h, and I presume this has affected the cvs tree adversely. Russell, can you explain/rectify this. Thanks muchly. --Tim From owner-linux-xfs@oss.sgi.com Tue Jan 16 16:33:59 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 16:33:52 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:54391 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 16:33:27 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA23353 for ; Tue, 16 Jan 2001 16:32:32 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA72397; Tue, 16 Jan 2001 18:32:11 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0H0VAd24903; Tue, 16 Jan 2001 18:31:10 -0600 Message-ID: <3A64E7CD.9A7B2EB9@thebarn.com> Date: Tue, 16 Jan 2001 18:31:09 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Timothy Shimmin CC: Drew Bloechl , linux-xfs@oss.sgi.com Subject: Re: CVS oddity References: <200101170018.LAA05445@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Timothy Shimmin wrote: > > > > > When doing a cvs update I get this: > > > > ... > > cvs server: Updating fs/xfs > > cvs server: Updating fs/xfs/dmapi > > cvs server: Updating fs/xfs/linux > > cvs server: Updating fs/xfs/pseudo-inc > > cvs server: cannot open directory > > /cvs/linux-2.4-xfs/linux/fs/xfs/pseudo-inc: No such file or directory > > cvs server: skipping directory fs/xfs/pseudo-inc > > I p_source_tree_remove'd (cmd from SGI's cvs equivalent) the last file > in this directory, fs/xfs/pseudo-inc/sys/acl.h, > and I presume this has affected the cvs tree adversely. > > Russell, can you explain/rectify this. > Thanks muchly. This is an inherent problem with the way the cvs tree is built. The tres essenstially is recustucted every hour from the ptools source. Normally cvs never deletes anything... it just moves it to the Attic, but by rebuilding the tree from the ptools tree every hour anything that is dropped from ptools does not get moved to the Attic it simply gets dropped. The only way to fix this problem is either recheck out the tree, or to manually remove the directory and the entry in the CVS/Entries file. The latter involves a lot less time and network bandwidth. This will always be a problem whenever files or directories are removed. Files cvs just goes hmm spits our a warning and cleans up but directories will involve manual help. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Jan 16 16:38:30 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 16:38:19 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:64632 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 16:38:09 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA23977 for ; Tue, 16 Jan 2001 16:37:13 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA36394 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 11:36:47 +1100 (EST) Date: Wed, 17 Jan 2001 11:36:47 +1100 (EST) From: Timothy Shimmin Message-Id: <200101170036.LAA36394@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - CREDITS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82379a Date: Tue Jan 16 16:35:58 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfsprogs/doc/CREDITS - 1.3 - Add Robert Stickel from Connex for contribution to ACL porting. Most likely be adding Danny Cox when get the go-ahead from him. From owner-linux-xfs@oss.sgi.com Tue Jan 16 17:40:09 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 17:39:59 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:34134 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 17:39:48 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA04843 for ; Tue, 16 Jan 2001 17:39:46 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA40370 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 12:38:26 +1100 (EST) Date: Wed, 17 Jan 2001 12:38:26 +1100 (EST) From: Nathan Scott Message-Id: <200101170138.MAA40370@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82387a Date: Tue Jan 16 17:36:55 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/dmapi/libdm/Makefile - 1.2 cmd/dmapi/libdm/dm_attr.c - 1.2 cmd/dmapi/libdm/dm_bulkattr.c - 1.2 cmd/dmapi/libdm/dm_config.c - 1.2 cmd/dmapi/libdm/dm_dmattr.c - 1.2 cmd/dmapi/libdm/dm_event.c - 1.2 cmd/dmapi/libdm/dm_handle.c - 1.2 cmd/dmapi/libdm/dm_handle2path.c - 1.2 cmd/dmapi/libdm/dm_hole.c - 1.2 cmd/dmapi/libdm/dm_mountinfo.c - 1.2 cmd/dmapi/libdm/dm_rdwr.c - 1.2 cmd/dmapi/libdm/dm_region.c - 1.2 cmd/dmapi/libdm/dm_right.c - 1.2 cmd/dmapi/libdm/dm_session.c - 1.2 cmd/dmapi/libdm/dmapi_lib.c - 1.2 cmd/dmapi/Makefile - 1.1 cmd/dmapi/Makepkgs - 1.1 cmd/dmapi/README - 1.1 cmd/dmapi/VERSION - 1.1 cmd/dmapi/build/Makefile - 1.1 cmd/dmapi/build/rpm/Makefile - 1.1 cmd/dmapi/build/rpm/dmapi.spec.in - 1.1 cmd/dmapi/build/rpm/macros.template - 1.1 cmd/dmapi/build/rpm/rpm-2.rc.template - 1.1 cmd/dmapi/build/tar/Makefile - 1.1 cmd/dmapi/configure.in - 1.1 cmd/dmapi/doc/CHANGES - 1.1 cmd/dmapi/doc/COPYING - 1.1 cmd/dmapi/doc/INSTALL - 1.1 cmd/dmapi/doc/Makefile - 1.1 cmd/dmapi/doc/PORTING - 1.1 cmd/dmapi/include/Makefile - 1.1 cmd/dmapi/include/builddefs.in - 1.1 cmd/dmapi/include/buildrules - 1.1 cmd/dmapi/include/dmapi.h - 1.1 cmd/dmapi/include/dmapi_kern.h - 1.1 cmd/dmapi/install-sh - 1.1 cmd/dmapi/man/Makefile - 1.1 cmd/dmapi/man/man3/Makefile - 1.1 cmd/dmapi/man/man3/dmapi.3 - 1.1 - initial version for reworked dmapi build environment. From owner-linux-xfs@oss.sgi.com Tue Jan 16 17:44:40 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 17:44:30 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:4619 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 17:44:29 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14IheE-0007yH-00 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 02:44:26 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14Ihe7-00085k-00 for ; Wed, 17 Jan 2001 02:44:19 +0100 Date: Wed, 17 Jan 2001 02:44:19 +0100 From: Jens Axboe To: linux-xfs@oss.sgi.com Subject: Re: REOPEN 804570 - The elevator bug Message-ID: <20010117024419.D30464@suse.de> References: <200101162324.PAA86202@info.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101162324.PAA86202@info.engr.sgi.com>; from pv@relay.sgi.com on Tue, Jan 16, 2001 at 03:24:22PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Jan 16 2001, srn@engr.sgi.com wrote: > As Jack noted, the temp patch mentioned in this pv has > been applied to the snia tree for now as a short term > fix for QA SNIA testing. This bug should probably not > have been closed since there's another more complete > fix in the works according to anath and chait. --steve Which bug was this specifically? -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Tue Jan 16 17:58:19 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 17:58:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:8981 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 17:57:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA04838 for ; Tue, 16 Jan 2001 17:56:53 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA88966 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 12:56:26 +1100 (EST) Date: Wed, 17 Jan 2001 12:56:26 +1100 (EST) From: Nathan Scott Message-Id: <200101170156.MAA88966@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - tests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82389a Date: Tue Jan 16 17:56:10 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfstests/tools/srcdiff - 1.3 - add a couple of dmapi headers to the set we cross check for consistency. From owner-linux-xfs@oss.sgi.com Tue Jan 16 20:04:29 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 20:04:10 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47700 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 20:03:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA00899 for ; Tue, 16 Jan 2001 20:12:41 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA57475 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 15:02:28 +1100 (EST) Date: Wed, 17 Jan 2001 15:02:28 +1100 (EST) From: Nathan Scott Message-Id: <200101170402.PAA57475@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82401a Date: Tue Jan 16 20:01:25 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/xfs/linux/xfs_file.c - 1.37 - fix a compiler warning. linux/fs/xfs/xfs.h - 1.14 linux/fs/xfs/xfs_dmapi.h - 1.15 linux/include/linux/dmapi_kern.h - 1.6 - slightly modify dmapi include ordering to assist header sharing with userspace. From owner-linux-xfs@oss.sgi.com Tue Jan 16 20:41:29 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 20:41:19 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:29260 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 20:41:11 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA26874 for ; Tue, 16 Jan 2001 20:40:15 -0800 (PST) mail_from (raa@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA487550; Tue, 16 Jan 2001 22:39:54 -0600 (CST) Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA67735; Tue, 16 Jan 2001 22:39:52 -0600 (CST) From: "Bob Albers Jr." Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id WAA27019; Tue, 16 Jan 2001 22:39:51 -0600 (CST) Message-Id: <200101170439.WAA27019@ioperf.americas.sgi.com> Date: Tue, 16 Jan 2001 22:39:51 -0600 (CST) To: nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: CLOSE 804570 - The elevator bug Cc: linux-xfs@oss.sgi.com, cbrady@sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com, mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com, raa@sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jack, Was this Jens Axboe's fix? Thanks, Bob From owner-linux-xfs@oss.sgi.com Tue Jan 16 20:46:50 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 20:46:30 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:39759 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 20:46:26 -0800 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA27949; Tue, 16 Jan 2001 20:45:30 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA76311; Tue, 16 Jan 2001 20:45:04 -0800 (PST) Date: Tue, 16 Jan 2001 20:45:04 -0800 (PST) Message-Id: <200101170445.UAA76311@feature.engr.sgi.com> X-Pv-Incident: 804570 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : coreym Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 01/16/01 *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: "bob albers jr." Date: Jan 16 2001 08:45:04PM [pvnews version: 1.71] ========================== Jack, Was this Jens Axboe's fix? Thanks, Bob From owner-linux-xfs@oss.sgi.com Tue Jan 16 23:26:40 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 23:26:30 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:18194 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 16 Jan 2001 23:26:08 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0H7Q2e26261; Wed, 17 Jan 2001 01:26:02 -0600 (CST) Message-ID: <3A654905.13AC01D8@thebarn.com> Date: Wed, 17 Jan 2001 01:25:57 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jens Axboe CC: linux-xfs@oss.sgi.com Subject: Re: REOPEN 804570 - The elevator bug References: <200101162324.PAA86202@info.engr.sgi.com> <20010117024419.D30464@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > On Tue, Jan 16 2001, srn@engr.sgi.com wrote: > > As Jack noted, the temp patch mentioned in this pv has > > been applied to the snia tree for now as a short term > > fix for QA SNIA testing. This bug should probably not > > have been closed since there's another more complete > > fix in the works according to anath and chait. --steve > > Which bug was this specifically? This is the infamous elevator starvation problem For XFS this means hammer on one part of the disk and log requests to a completely different part of the disk will get starved out. BTW what is the status of this patch in regards to the actual 2.4.x tree? Somebody mentioned one of the 2.4.1-acX had it included? Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 16 23:43:30 2001 Received: by oss.sgi.com id ; Tue, 16 Jan 2001 23:43:20 -0800 Received: from [192.117.188.36] ([192.117.188.36]:17670 "HELO mail.tapuz.co.il") by oss.sgi.com with SMTP id ; Tue, 16 Jan 2001 23:42:56 -0800 Received: from csdc094 ([156.153.255.171]) by mail.tapuz.co.il ; Wed, 17 Jan 2001 09:56:10 +0000 Message-ID: <002a01c08059$125be1b0$5ef1d092@chn.agilent.com> From: "kerler" To: Subject: What is the most minimum size of XFS? Date: Wed, 17 Jan 2001 15:42:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, What is the most minimum size of XFS? thanks From owner-linux-xfs@oss.sgi.com Wed Jan 17 00:13:10 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 00:13:00 -0800 Received: from plato.arts.usyd.edu.au ([129.78.16.1]:43527 "EHLO plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 00:12:44 -0800 Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id TAA22198; Wed, 17 Jan 2001 19:12:31 +1100 (EST) Message-ID: <3A655431.3B4F2539@arts.usyd.edu.au> Date: Wed, 17 Jan 2001 19:13:37 +1100 From: Matthew Geier Organization: Arts IT Unit, Sydney University X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: kerler CC: linux-xfs@oss.sgi.com Subject: Re: What is the most minimum size of XFS? References: <002a01c08059$125be1b0$5ef1d092@chn.agilent.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms441E97D73A5A51380362BE07" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a cryptographically signed message in MIME format. --------------ms441E97D73A5A51380362BE07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit kerler wrote: > > Hello, > > What is the most minimum size of XFS? > It's happy with a 100mb zip disk. I haven't tried a 1.4mb floppy yet :-) --------------ms441E97D73A5A51380362BE07 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH4AYJKoZIhvcNAQcCoIIH0TCCB80CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BckwggKtMIICFqADAgECAgMC8UswDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyMTAyNDAzNFoXDTAxMDcyMTAyNDAz NFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3DQEJARYY bWF0dGhld0BhcnRzLnVzeWQuZWR1LmF1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDR gAKbBhCplgqyhkR0Ykn4XOW0Py1G40orbP+B2KkACTMx4GxhHNg2h3nPiNC/P/9BZETw6NA+ dp/mxtN7XHmvRounnCL+9pjG3yWpw/ONNEpObjRSfujGe/jJvUF2vrAfecI/J5DKQ0/5gZMv 5fqfl4spYSPl+9vc2hKG7uvjgQIDAQABo1YwVDAjBgNVHREEHDAagRhtYXR0aGV3QGFydHMu dXN5ZC5lZHUuYXUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORYx0YdwGG9 I9fDjDANBgkqhkiG9w0BAQQFAAOBgQBjjvY9P9hSktFnCJrkQSTKjh9ZBG9a58a0Hi+GvmyD t9e29sRgxHN+Nwtsu2yUs8+xv1BemYzCnri+y91uJsfRTrm4+1oc/TV+lDGWqBud68wf4x29 /xaj1oQ2vWMy1Y64KZSWyxjt+vcU5/nyNF3DGz9XtXlxTI8dntzEWkyq/DCCAxQwggJ9oAMC AQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxs ZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn /XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESw iy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL3Vx1b8aR kMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6syg1vcnpn LGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAd8wggHbAgEBMIGcMIGUMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UE ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAvFLMAkGBSsOAwIaBQCggZkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTE3MDgxMzQxWjAjBgkq hkiG9w0BCQQxFgQUON/OiV2OF32mfx9dZGFM/RhodowwOgYJKoZIhvcNAQkPMS0wKzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwDQYJKoZIhvcNAQEBBQAE gYBfLbI23lShmIFWn0QalgCHe4kV23F9sbYLYDg8SYzGwWgkPVaDkmV1dhFumLsbkybAd+sO bymvpHvHnpQYBw9l15I5ryhS80j80kpxTD9GxXV0GbrDT1EpvTZmusGcGEme8ROc/qGk+KeB pJ1kshbiAA1H/yQ9jGrYy1zjbSwbXA== --------------ms441E97D73A5A51380362BE07-- From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:39:42 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:39:32 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36976 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:39:22 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA02214; Wed, 17 Jan 2001 06:48:14 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id GAA74721; Wed, 17 Jan 2001 06:39:20 -0800 (PST) Date: Wed, 17 Jan 2001 06:39:20 -0800 (PST) Message-Id: <200101171439.GAA74721@info.engr.sgi.com> X-Pv-Incident: 804570 webPV: ioperf.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570 *CC List : raa@sgi.com huovinen@sgi.com cattelan@sgi.com mann@sgi.com tbd@sgi.com rrl@sgi.com alaffin@sgi.com cbrady@sgi.com eac@sgi.com hasib@sgi.com coreym@sgi.com Status : open Priority : 3 Assigned Engineer : nb Submitter : coreym *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: raa@sgi.com (BugWorks) Date: Jan 17 2001 06:39:19AM ========================== From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:42:11 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:42:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:56606 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:41:52 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA14483; Wed, 17 Jan 2001 06:40:56 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id GAA10730; Wed, 17 Jan 2001 06:41:51 -0800 (PST) Date: Wed, 17 Jan 2001 06:41:51 -0800 (PST) Message-Id: <200101171441.GAA10730@info.engr.sgi.com> X-Pv-Incident: 804570 webPV: ioperf.americas.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570 *CC List : raa@sgi.com huovinen@sgi.com cattelan@sgi.com mann@sgi.com tbd@sgi.com rrl@sgi.com alaffin@sgi.com cbrady@sgi.com eac@sgi.com hasib@sgi.com coreym@sgi.com steiner@sgi.com Status : open Priority : 3 Assigned Engineer : nb Submitter : coreym *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: raa@sgi.com (BugWorks) Date: Jan 17 2001 06:41:50AM ========================== From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:44:31 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:44:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:49196 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:43:59 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA00944 for ; Wed, 17 Jan 2001 06:43:58 -0800 (PST) mail_from (raa@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA491271; Wed, 17 Jan 2001 08:42:42 -0600 (CST) Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA98326; Wed, 17 Jan 2001 08:42:40 -0600 (CST) From: "Bob Albers Jr." Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA27761; Wed, 17 Jan 2001 08:42:39 -0600 (CST) Message-Id: <200101171442.IAA27761@ioperf.americas.sgi.com> Date: Wed, 17 Jan 2001 08:42:39 -0600 (CST) To: nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: ADD 804570 - The elevator bug Cc: linux-xfs@oss.sgi.com, steiner@sgi.com, coreym@sgi.com, hasib@sgi.com, eac@sgi.com, cbrady@sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com, mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com, raa@sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing From raa@sgi.com Tue Dec 19 17:27:47 2000 From: "Bob Albers Jr." Date: Tue, 19 Dec 2000 17:27:53 -0600 (CST) To: "Bob Albers Jr." , Steve Reinhardt Subject: Re: when can we expect PV 804570 fixed? Cc: jwright@sgi.com, nb@sgi.com, loriann@sgi.com, btg@sgi.com (brian gaffey), Steve Reinhardt , "Bob Albers Jr." Good news regarding the elevator stall problem - Jens Axboe of the community has fixed this problem. We tested it and it works. So now we have to wait for Linus to accept this fix and for it to show up in a kernel. Bob From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:47:01 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:46:41 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:42285 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:46:27 -0800 Received: from feature.engr.sgi.com ([130.62.42.134]) 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 GAA03264; Wed, 17 Jan 2001 06:46:26 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA90173; Wed, 17 Jan 2001 06:45:04 -0800 (PST) Date: Wed, 17 Jan 2001 06:45:04 -0800 (PST) Message-Id: <200101171445.GAA90173@feature.engr.sgi.com> X-Pv-Incident: 804570 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : coreym Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 01/17/01 *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: "bob albers jr." Date: Jan 17 2001 06:45:04AM [pvnews version: 1.71] ========================== >From raa@sgi.com Tue Dec 19 17:27:47 2000 From: "Bob Albers Jr." Date: Tue, 19 Dec 2000 17:27:53 -0600 (CST) To: "Bob Albers Jr." , Steve Reinhardt Subject: Re: when can we expect PV 804570 fixed? Cc: jwright@sgi.com, nb@sgi.com, loriann@sgi.com, btg@sgi.com (brian gaffey), Steve Reinhardt , "Bob Albers Jr." Good news regarding the elevator stall problem - Jens Axboe of the community has fixed this problem. We tested it and it works. So now we have to wait for Linus to accept this fix and for it to show up in a kernel. Bob From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:48:12 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:48:01 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:10030 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:47:47 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA02784 for ; Wed, 17 Jan 2001 06:47:46 -0800 (PST) mail_from (raa@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA489884; Wed, 17 Jan 2001 08:46:29 -0600 (CST) Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA01296; Wed, 17 Jan 2001 08:46:28 -0600 (CST) From: "Bob Albers Jr." Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA27703; Wed, 17 Jan 2001 08:46:27 -0600 (CST) Message-Id: <200101171446.IAA27703@ioperf.americas.sgi.com> Date: Wed, 17 Jan 2001 08:46:27 -0600 (CST) To: nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: ADD 804570 - The elevator bug Cc: srn@engr.sgi.com, chait@engr.sgi.com, ananth@engr.sgi.com, linux-xfs@oss.sgi.com, steiner@sgi.com, coreym@sgi.com, hasib@sgi.com, eac@sgi.com, cbrady@sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com, mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com, raa@sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Russell, Could you reply to this PV regarding the elevator tuning parameters that can be used to significantly reduce the elevator stalls. Could you also note what they should be set to and how. Ananth or Chait, Could you respond to this PV with your evaluation of Jens' elevator fix and if it would be a good fit for the SN-IA64 kernel. Thanks, Bob From owner-linux-xfs@oss.sgi.com Wed Jan 17 06:51:51 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:51:32 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:29743 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 06:51:22 -0800 Received: from feature.engr.sgi.com ([130.62.42.134]) 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 GAA03028; Wed, 17 Jan 2001 06:51:22 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA90184; Wed, 17 Jan 2001 06:50:03 -0800 (PST) Date: Wed, 17 Jan 2001 06:50:03 -0800 (PST) Message-Id: <200101171450.GAA90184@feature.engr.sgi.com> X-Pv-Incident: 804570 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : coreym Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 01/17/01 *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: "bob albers jr." Date: Jan 17 2001 06:50:03AM [pvnews version: 1.71] ========================== Russell, Could you reply to this PV regarding the elevator tuning parameters that can be used to significantly reduce the elevator stalls. Could you also note what they should be set to and how. Ananth or Chait, Could you respond to this PV with your evaluation of Jens' elevator fix and if it would be a good fit for the SN-IA64 kernel. Thanks, Bob From owner-linux-xfs@oss.sgi.com Wed Jan 17 07:00:01 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 06:59:52 -0800 Received: from Cantor.suse.de ([194.112.123.193]:29190 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 17 Jan 2001 06:59:35 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 1D7F91E286; Wed, 17 Jan 2001 15:59:30 +0100 (MET) Date: Wed, 17 Jan 2001 15:59:17 +0100 From: Andi Kleen To: "Bob Albers Jr." Cc: nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com, linux-xfs@oss.sgi.com, steiner@sgi.com, coreym@sgi.com, hasib@sgi.com, eac@sgi.com, cbrady@sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com, mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com Subject: Re: ADD 804570 - The elevator bug Message-ID: <20010117155917.A30529@gruyere.muc.suse.de> References: <200101171442.IAA27761@ioperf.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: <200101171442.IAA27761@ioperf.americas.sgi.com>; from raa@sgi.com on Wed, Jan 17, 2001 at 08:42:39AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 17, 2001 at 08:42:39AM -0600, Bob Albers Jr. wrote: > >From raa@sgi.com Tue Dec 19 17:27:47 2000 > From: "Bob Albers Jr." > Date: Tue, 19 Dec 2000 17:27:53 -0600 (CST) > To: "Bob Albers Jr." , Steve Reinhardt > Subject: Re: when can we expect PV 804570 fixed? > Cc: jwright@sgi.com, nb@sgi.com, loriann@sgi.com, btg@sgi.com (brian gaffey), > Steve Reinhardt , "Bob Albers Jr." > > > Good news regarding the elevator stall problem - Jens Axboe of the community > has fixed this problem. We tested it and it works. So now we have to wait for > Linus to accept this fix and for it to show up in a kernel. The elevator fixes are in 2.4.1pre7 -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 17 07:06:52 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 07:06:32 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:43818 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 07:06:26 -0800 Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA18736; Wed, 17 Jan 2001 07:05:30 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA90532; Wed, 17 Jan 2001 07:05:05 -0800 (PST) Date: Wed, 17 Jan 2001 07:05:05 -0800 (PST) Message-Id: <200101171505.HAA90532@feature.engr.sgi.com> X-Pv-Incident: 804570 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (ak@suse.de.sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : coreym Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 01/17/01 *Modified User : ak *Modified User Domain : suse.de *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: andi kleen Date: Jan 17 2001 07:05:04AM [pvnews version: 1.71] ========================== On Wed, Jan 17, 2001 at 08:42:39AM -0600, Bob Albers Jr. wrote: > >From raa@sgi.com Tue Dec 19 17:27:47 2000 > From: "Bob Albers Jr." > Date: Tue, 19 Dec 2000 17:27:53 -0600 (CST) > To: "Bob Albers Jr." , Steve Reinhardt > Subject: Re: when can we expect PV 804570 fixed? > Cc: jwright@sgi.com, nb@sgi.com, loriann@sgi.com, btg@sgi.com (brian gaffey), > Steve Reinhardt , "Bob Albers Jr." > > > Good news regarding the elevator stall problem - Jens Axboe of the community > has fixed this problem. We tested it and it works. So now we have to wait for > Linus to accept this fix and for it to show up in a kernel. The elevator fixes are in 2.4.1pre7 -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 17 07:18:32 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 07:18:22 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:29711 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 07:18:01 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14IuLJ-0003ZV-00; Wed, 17 Jan 2001 16:17:45 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14IuLE-0006ed-00; Wed, 17 Jan 2001 16:17:40 +0100 Date: Wed, 17 Jan 2001 16:17:40 +0100 From: Jens Axboe To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: REOPEN 804570 - The elevator bug Message-ID: <20010117161740.B25507@suse.de> References: <200101162324.PAA86202@info.engr.sgi.com> <20010117024419.D30464@suse.de> <3A654905.13AC01D8@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A654905.13AC01D8@thebarn.com>; from cattelan@thebarn.com on Wed, Jan 17, 2001 at 01:25:57AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 17 2001, Russell Cattelan wrote: > > On Tue, Jan 16 2001, srn@engr.sgi.com wrote: > > > As Jack noted, the temp patch mentioned in this pv has > > > been applied to the snia tree for now as a short term > > > fix for QA SNIA testing. This bug should probably not > > > have been closed since there's another more complete > > > fix in the works according to anath and chait. --steve > > > > Which bug was this specifically? > > This is the infamous elevator starvation problem > For XFS this means hammer on one part of the disk > and log requests to a completely different part of the disk > will get starved out. Exactly, it's been known for some time that the sequencing in the stock kernel was much too high. dbench tuned :-) > BTW what is the status of this patch in regards to the > actual 2.4.x tree? > Somebody mentioned one of the 2.4.1-acX had it included? It was integrated in -acX yes, and Linus also took it now. 2.4.1-pre5 has blk-13C integration, pre6 adds a couple of further optimizations. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Wed Jan 17 09:45:52 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 09:45:43 -0800 Received: from mcomail01.maxtor.com ([134.6.76.15]:34569 "HELO mcomail01.maxtor.com") by oss.sgi.com with SMTP id ; Wed, 17 Jan 2001 09:45:34 -0800 Received: from 134.6.67.21 by mcomail01.maxtor.com (InterScan E-Mail VirusWall NT); Wed, 17 Jan 2001 10:40:05 -0700 (Mountain Standard Time) Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 10:45:17 -0700 Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com> From: "Davida, Joe" To: "'linux-xfs@oss.sgi.com '" Subject: RE: xfs block size Date: Wed, 17 Jan 2001 10:45:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On the web page you sited, I read: "...We are using pages to cache metadata, pages are allocated one at a time, so each page sized chunk of memory usually is not adjacent in the address space to the page covering the next block of the disk." How does FreeBSD's UFS let you mkfs filesystems with 16K FS pagesize? It is on same X86 architecture as Linux! Also, why does the XFS have to allocate metadata pages that are same size as FS logical block size? At the expense of trying to answer my own question, I vaguely recall reading - and I might be wrong here - that for very small files, the file data is stored in the metadata (inode) page, which is only 1 mmu-sized 4K page. Is this correct?, and if so, a. Is this the primary reason why you currently only support 4K FS logical block size? b. Could this be removed, and make all data live in seperate data blocks (extents) in the tree, as is the case with large files? c. Could it be made dependent on user selected block size during mkfs? i.e., if user selects 4K blocksize, then default to current implementation, else let all metadata live in in pages seperately from data. Cheers, Joe >-----Original Message----- >From: Nathan Scott [mailto:nathans@wobbly.melbourne.sgi.com] >Sent: Tuesday, January 16, 2001 7:31 AM >To: Davida, Joe; 'linux-xfs@oss.sgi.com ' >Subject: Re: xfs block size > > >hi Joe, > >On Jan 12, 1:24pm, Davida, Joe wrote: >> Subject: xfs block size >> Are there any plans to support 64K FS block >> sizes? >> How soon (ballpark date)? >> In what version of Linux (2.4, 2.5...etc)? >> > >Yes, there are plans - details are at: >http://oss.sgi.com/projects/xfs/todos.html#_multiblocksize > >>From a conversation with Russell, he's predicted an eta of >around 3 - 6 months from now (also saying that at the moment >its not clear exactly what the solution will be and that >there's plenty on his plate before getting onto this issue). > >We'd be looking at a 2.4.x+XFS tree I would imagine. > >cheers. > >-- >Nathan > From owner-linux-xfs@oss.sgi.com Wed Jan 17 11:39:55 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 11:39:46 -0800 Received: from ns.caldera.de ([212.34.180.1]:47878 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 11:39:34 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id UAA23152; Wed, 17 Jan 2001 20:38:52 +0100 Date: Wed, 17 Jan 2001 20:38:52 +0100 From: Christoph Hellwig To: "Davida, Joe" Cc: "'linux-xfs@oss.sgi.com '" Subject: Re: xfs block size Message-ID: <20010117203852.B22384@caldera.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com>; from Joe_Davida@Maxtor.com on Wed, Jan 17, 2001 at 10:45:17AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 17, 2001 at 10:45:17AM -0700, Davida, Joe wrote: > On the web page you sited, I read: > > "...We are using pages to cache metadata, pages are > allocated one at a time, so each page sized chunk > of memory usually is not adjacent in the address > space to the page covering the next block of the > disk." > > How does FreeBSD's UFS let you mkfs filesystems > with 16K FS pagesize? It is on same X86 architecture > as Linux! But it is not Linux. They do organize things differently. (Linux UFS support larger blocks too, but it seems pretty b0rken currently) Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Wed Jan 17 11:54:26 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 11:54:16 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:57165 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 11:54:10 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20751 for ; Wed, 17 Jan 2001 11:53:14 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA496292; Wed, 17 Jan 2001 13:52:52 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA53459; Wed, 17 Jan 2001 13:52:52 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0HJs2T01301; Wed, 17 Jan 2001 13:54:02 -0600 Message-Id: <200101171954.f0HJs2T01301@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Davida, Joe" cc: "'linux-xfs@oss.sgi.com '" Subject: Re: xfs block size In-Reply-To: Message from "Davida, Joe" of "Wed, 17 Jan 2001 10:45:17 MST." <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com> Date: Wed, 17 Jan 2001 13:54:02 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On the web page you sited, I read: > > "...We are using pages to cache metadata, pages are > allocated one at a time, so each page sized chunk > of memory usually is not adjacent in the address > space to the page covering the next block of the > disk." > > How does FreeBSD's UFS let you mkfs filesystems > with 16K FS pagesize? It is on same X86 architecture > as Linux! A. It is a totally different filesystem running on a different operating system. > > Also, why does the XFS have to allocate metadata > pages that are same size as FS logical block size? > At the expense of trying to answer my own question, > I vaguely recall reading - and I might be wrong here - > that for very small files, the file data is stored > in the metadata (inode) page, which is only 1 > mmu-sized 4K page. > Is this correct?, and if so, This is not correct, XFS does not store data for small files in the inode - half the support is there - a nice project for someone who wants to really get to know XFS. The reason for XFS being this way is that it was originally written on an OS where the kernel guaranteed the availability of large chunks of contiguous memory in the kernel, linux does not guarantee this, the larger the size memory you ask for in the kernel, the greater the chance the allocation will fail, it will not fail at the page size level unless things are really bad. Some of the metadata structures in XFS are extremely complex (directory blocks, btree structures etc). The code which manipulates these is all written under the assumption that you can read them into a buffer, and then manipulate them as a contiguous chunk of memory. Rewriting this code is not an option because a) it would destroy the stability of the filesystem (the current code base probably has millions of cpu hours on it on Irix) and b) it would be a very large task. This leaves us with finding ways of getting contiguous memory in a guaranteed manner. One option was to use the VM system to remap the pages into contiguous address space - this has been rejected because: a) Linus has many times stated he will not accept code that does this, b) it is an expensive operation on the intel architecture - especially once you have multiple cpus (it involves interrupting them all and synchronizing them). Finally, this work has not been at the top of our priority list, and may not be for some time. However, it does appear to be high on your list, and has been for some time. Since Maxtor is looking at xfs from the point of view of something it could use in a product it makes money off, you should perhaps be making more of an investment in Linux here. Steve > a. Is this the primary reason why you currently only > support 4K FS logical block size? > > b. Could this be removed, and make all data live in > seperate data blocks (extents) in the tree, as is > the case with large files? > > c. Could it be made dependent on user selected block > size during mkfs? i.e., if user selects 4K blocksize, > then default to current implementation, else > let all metadata live in in pages seperately from > data. > > Cheers, > > Joe > > From owner-linux-xfs@oss.sgi.com Wed Jan 17 12:14:26 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 12:14:16 -0800 Received: from Cantor.suse.de ([194.112.123.193]:22796 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 17 Jan 2001 12:13:54 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 08BD71E308; Wed, 17 Jan 2001 21:13:52 +0100 (MET) Date: Wed, 17 Jan 2001 21:13:19 +0100 From: Andi Kleen To: Christoph Hellwig Cc: "Davida, Joe" , "'linux-xfs@oss.sgi.com '" Subject: Re: xfs block size Message-ID: <20010117211319.A5369@gruyere.muc.suse.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com> <20010117203852.B22384@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010117203852.B22384@caldera.de>; from hch@ns.caldera.de on Wed, Jan 17, 2001 at 08:38:52PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 17, 2001 at 08:38:52PM +0100, Christoph Hellwig wrote: > On Wed, Jan 17, 2001 at 10:45:17AM -0700, Davida, Joe wrote: > > On the web page you sited, I read: > > > > "...We are using pages to cache metadata, pages are > > allocated one at a time, so each page sized chunk > > of memory usually is not adjacent in the address > > space to the page covering the next block of the > > disk." > > > > How does FreeBSD's UFS let you mkfs filesystems > > with 16K FS pagesize? It is on same X86 architecture > > as Linux! > > But it is not Linux. They do organize things differently. > (Linux UFS support larger blocks too, but it seems pretty b0rken > currently) iirc one of the plans for 2.5 is to move to bigger logical (and physical on systems that support it like ia64) page sizes similar to Irix. Hopefully that will help XFS too. vmalloc got a bit cheaper in 2.4 now, no ipi needed on alloc anymore, just on free, but it's probably still not a real option for any regular executed path. -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 17 12:20:06 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 12:19:56 -0800 Received: from ns.caldera.de ([212.34.180.1]:14343 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 12:19:41 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id VAA27619; Wed, 17 Jan 2001 21:19:26 +0100 Date: Wed, 17 Jan 2001 21:19:26 +0100 From: Christoph Hellwig To: Andi Kleen Cc: "Davida, Joe" , "'linux-xfs@oss.sgi.com '" Subject: Re: xfs block size Message-ID: <20010117211926.A27445@caldera.de> References: <09D1E9BD9C30D311919200A0C9DD5C2C025370A4@mcaexc01.msj.maxtor.com> <20010117203852.B22384@caldera.de> <20010117211319.A5369@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010117211319.A5369@gruyere.muc.suse.de>; from ak@suse.de on Wed, Jan 17, 2001 at 09:13:19PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 17, 2001 at 09:13:19PM +0100, Andi Kleen wrote: > > But it is not Linux. They do organize things differently. > > (Linux UFS support larger blocks too, but it seems pretty b0rken > > currently) > > iirc one of the plans for 2.5 is to move to bigger logical (and physical on > systems that support it like ia64) page sizes similar to Irix. IMHO this is a pretty good idea, and I think it's time to do it. Daniel Phillips' variable page sizes idea looks also pretty interesting in this context. > Hopefully that will help XFS too. I bet. On the other hand XFS does pretty well even with 4K blocks/pagesize due to the use of extends. > > vmalloc got a bit cheaper in 2.4 now, no ipi needed on alloc anymore, just on > free, but it's probably still not a real option for any regular executed path. Agreed. Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Wed Jan 17 12:43:35 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 12:43:26 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:41732 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 12:43:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA13378 for ; Wed, 17 Jan 2001 12:42:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA497494; Wed, 17 Jan 2001 14:39:25 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA56813; Wed, 17 Jan 2001 14:39:24 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0HKeYC01488; Wed, 17 Jan 2001 14:40:34 -0600 Message-Id: <200101172040.f0HKeYC01488@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "kerler" cc: linux-xfs@oss.sgi.com Subject: Re: What is the most minimum size of XFS? In-Reply-To: Message from "kerler" of "Wed, 17 Jan 2001 15:42:15 +0800." <002a01c08059$125be1b0$5ef1d092@chn.agilent.com> Date: Wed, 17 Jan 2001 14:40:34 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello, > > What is the most minimum size of XFS? > > thanks > > I have not investigated why, but this generates a filesystem image: mkfs -t xfs -d file,name=/tmp/fred,size=4852k and this does not mkfs -t xfs -d file,name=/tmp/fred,size=4851k so too big for a floppy, but small enough for most other devices. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 17 15:08:15 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 15:08:05 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48943 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 15:07:52 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04049 for ; Wed, 17 Jan 2001 15:16:44 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA48639 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 10:06:29 +1100 (EST) Date: Thu, 18 Jan 2001 10:06:29 +1100 (EST) From: Timothy Shimmin Message-Id: <200101172306.KAA48639@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - CREDITS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82435a Date: Wed Jan 17 15:06:06 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfsprogs/doc/CREDITS - 1.4 - Adding Danny Cox for ACL porting effort. From owner-linux-xfs@oss.sgi.com Wed Jan 17 18:38:26 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 18:38:16 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:21351 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 18:37:58 -0800 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA11483 for ; Wed, 17 Jan 2001 18:37:02 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f0I2aJm12998 for linux-xfs@oss.sgi.com; Wed, 17 Jan 2001 18:36:19 -0800 Date: Wed, 17 Jan 2001 18:36:19 -0800 From: Ananth Ananthanarayanan Message-Id: <200101180236.f0I2aJm12998@waco.engr.sgi.com> Subject: TAKE - use atomic allocation on flush To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Jan 17 18:36:20 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-delalloc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82449a linux/fs/pagebuf/page_buf_io.c - 1.40 - Use non-blocking memory allocation since flush can be called from kswapd which shouldn't block. From owner-linux-xfs@oss.sgi.com Wed Jan 17 19:03:15 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 19:03:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33605 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 19:02:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA06456 for ; Wed, 17 Jan 2001 19:11:42 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA39975 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 14:01:28 +1100 (EST) Date: Thu, 18 Jan 2001 14:01:28 +1100 (EST) From: Nathan Scott Message-Id: <200101180301.OAA39975@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82451a Date: Wed Jan 17 19:01:17 PST 2001 Workarea: snort:/diskb/build4/nathans/quota-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Makefile - 1.36 - tidy up some leftovers missed after I merged Toms ia64 changes with my changes. From owner-linux-xfs@oss.sgi.com Wed Jan 17 19:06:46 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 19:06:36 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43077 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 19:06: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 TAA01877 for ; Wed, 17 Jan 2001 19:15:17 -0800 (PST) mail_from (raa@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA501104; Wed, 17 Jan 2001 21:05:07 -0600 (CST) Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA80585; Wed, 17 Jan 2001 21:05:04 -0600 (CST) From: "Bob Albers Jr." Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id VAA28838; Wed, 17 Jan 2001 21:05:04 -0600 (CST) Message-Id: <200101180305.VAA28838@ioperf.americas.sgi.com> Date: Wed, 17 Jan 2001 21:05:04 -0600 (CST) To: nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: Re: ADD 804570 - The elevator bug Cc: linux-xfs@oss.sgi.com, steiner@sgi.com, coreym@sgi.com, hasib@sgi.com, eac@sgi.com, cbrady@sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com, mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com, raa@sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing From axboe@brick.kernel.dk Wed Jan 17 09:16:29 2001 Date: Wed, 17 Jan 2001 16:16:10 +0100 From: Jens Axboe To: Rajagopal Ananthanarayanan Cc: srn@sgi.com, chait@sgi.com, raa@sgi.com Subject: Re: Elevator stall fix On Wed, Jan 17 2001, Rajagopal Ananthanarayanan wrote: > > Hi Jens, > > Could you please send us a pointer to your latest > patch that fixes a problem where some requests were always > by-passing other requests in the elevator queue? Since > ELEVATOR_LINUS had tuneables set so high, the by-pass > was percieved as a virtual stall. The patch is blk-13C, before integration in 2.4.0-acX it was renamed to blk-14 because I added some low mem hysterisis. *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-ac4/blk-13C.bz2 is the latest non-integrated patch. > This patch is the one that Linus specifically said is > being considered for inclusion in 2.4.1. The problem > was reported by someone from Japan a couple of months > back and even LWN (lwn.com) ran an article about it > at that time. Yes, Linus integrated blk-13C in 2.4.1-pre5, and pre6 went to blk-14. So the patch is in the main tree now. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Wed Jan 17 19:11:46 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 19:11:35 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:51981 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 19:11:25 -0800 Received: from feature.engr.sgi.com ([130.62.42.134]) 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 TAA08014; Wed, 17 Jan 2001 19:11:26 -0800 (PST) mail_from (pv@feature.engr.sgi.com) Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA05395; Wed, 17 Jan 2001 19:10:04 -0800 (PST) Date: Wed, 17 Jan 2001 19:10:04 -0800 (PST) Message-Id: <200101180310.TAA05395@feature.engr.sgi.com> X-Pv-Incident: 804570 Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (raa@sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Submitter : coreym Status : open Assigned Engineer : nb Priority : 3 *Modified Date : 01/17/01 *Modified User : raa *Modified User Domain : sgi.com *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: "bob albers jr." Date: Jan 17 2001 07:10:04PM [pvnews version: 1.71] ========================== >From axboe@brick.kernel.dk Wed Jan 17 09:16:29 2001 Date: Wed, 17 Jan 2001 16:16:10 +0100 From: Jens Axboe To: Rajagopal Ananthanarayanan Cc: srn@sgi.com, chait@sgi.com, raa@sgi.com Subject: Re: Elevator stall fix On Wed, Jan 17 2001, Rajagopal Ananthanarayanan wrote: > > Hi Jens, > > Could you please send us a pointer to your latest > patch that fixes a problem where some requests were always > by-passing other requests in the elevator queue? Since > ELEVATOR_LINUS had tuneables set so high, the by-pass > was percieved as a virtual stall. The patch is blk-13C, before integration in 2.4.0-acX it was renamed to blk-14 because I added some low mem hysterisis. *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-ac4/blk-13C.bz2 is the latest non-integrated patch. > This patch is the one that Linus specifically said is > being considered for inclusion in 2.4.1. The problem > was reported by someone from Japan a couple of months > back and even LWN (lwn.com) ran an article about it > at that time. Yes, Linus integrated blk-13C in 2.4.1-pre5, and pre6 went to blk-14. So the patch is in the main tree now. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Wed Jan 17 20:32:05 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 20:31:55 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:23593 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 20:31:29 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07999 for ; Wed, 17 Jan 2001 20:31:28 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA11207 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 15:30:07 +1100 (EST) Date: Thu, 18 Jan 2001 15:30:07 +1100 (EST) From: Timothy Shimmin Message-Id: <200101180430.PAA11207@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82473a Date: Wed Jan 17 20:29:40 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/include/acl.h - 1.2 linux/include/linux/acl.h - 1.2 - Delete prototypes whose functions are not implemented in the libacl library. From owner-linux-xfs@oss.sgi.com Wed Jan 17 20:39:55 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 20:39:45 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:36907 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 20:39:32 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05166 for ; Wed, 17 Jan 2001 20:39:32 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA02362 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 15:38:11 +1100 (EST) Date: Thu, 18 Jan 2001 15:38:11 +1100 (EST) From: Nathan Scott Message-Id: <200101180438.PAA02362@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82474a Date: Wed Jan 17 20:38:02 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.2 - add an Obsoletes line for a smoother upgrade path. From owner-linux-xfs@oss.sgi.com Wed Jan 17 22:52:36 2001 Received: by oss.sgi.com id ; Wed, 17 Jan 2001 22:52:27 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:57861 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Wed, 17 Jan 2001 22:52:15 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0I6q7e43428; Thu, 18 Jan 2001 00:52:12 -0600 (CST) Message-ID: <3A669292.BBDFE0B5@thebarn.com> Date: Thu, 18 Jan 2001 00:52:02 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mkp@linuxcare.com CC: linux-xfs@oss.sgi.com Subject: So you want to be a mirror site. Content-Type: multipart/mixed; boundary="------------97265A97C78693C57B224BD1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. --------------97265A97C78693C57B224BD1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok after a bunch of fiddling I finally have the script working fairly well. This should build a directory the contains all the original RH7.0+Updates+XFS and regen the hdlist file. Rerunning the script whenever new update come out should correctly delete the old ones and replaces them with the newer version. Note sometime is over ambitious with the deletes... don't worry about it the will get re-updated. The rest of the notes are in the script. Note oss.sgi.com will not be offering this fully integrated install directory right away, but anybody wishing to be a mirror site please do and let us know so we can put a list up. Ohh one more thing the latest version of glibc is glibc-2.2. which does not seem meet the rpm requirements of a most packages. which is looking for glibc-2.1 I don't know where the goof up is yet... I'm have to look at the source rpm and find out. For the moment telling the installer to ignore the dependencies seems get around the problem. --------------97265A97C78693C57B224BD1 Content-Type: application/x-perl; name="updateCD.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="updateCD.pl" #!/usr/bin/perl # rsync and genhdlist must be installed before running this script. # gendhlist is part of the anoconda-runtime paackage. # rsync is it's own package. use strict; use Data::Dumper; use File::Find (); # for the convenience of &wanted calls, including -eval statements: use vars qw/*name *dir *prune/; *name = *File::Find::name; *dir = *File::Find::dir; *prune = *File::Find::prune; my $RHVERSION="7.0"; my $ARCH="i386"; my $LANG="en"; # The next three lines must be changed. my $RHROOT = "/export/hole/redhat/redhat-${RHVERSION}"; my $DESTDIR = "/export/blam/FULL"; my $SGIROOT = '/build2/rh7-sgi-installer/sgiInstall'; # The following command will set up RHROOT and SGIROOT # rsync --exclude redhat-6.2 --delete -av ftp.borg.umn.edu::ftp/redhat/ $RHROOT # /rsync --delete -aLv oss.sgi.com::xfsftp/SGI-XFS-latest/ $SGIROOT my $genhdlist = '/usr/lib/anaconda-runtime/genhdlist'; # Note: This script works by using a keyed hash. # Each rpm is keyed into the hash my NAME and ARCHITECTURE # The following list of directories must be in order # of oldest rpms to newest rpms. # Each time a newer version of an rpm is found it # knocks the old one of the hash and puts it on a # list to be deleted. my @rpmdirs = ("$RHROOT/$ARCH/$LANG/RedHat/RPMS", "$RHROOT/updates/i386", "$RHROOT/updates/i586", "$RHROOT/updates/i686", "$SGIROOT/RedHat/RPMS"); my @rpms; my %rpmkeys; my @delete = (); #print Dumper($rpmdirs); $dir = "$DESTDIR/RedHat/RPMS"; if ( ! -d $dir ){ system("mkdir -p $DESTDIR/RedHat/RPMS/"); } else { File::Find::find({wanted => \&wanted}, $dir); foreach my $rpm (@rpms){ my $rpmname = `rpm --queryformat "%{NAME}%{ARCH}" -qp $rpm`; # seed the list so we know where the conflicts are and which onces to delete $rpmkeys{$rpmname} = $rpm; } } foreach my $dir (@rpmdirs){ @rpms = (); print "Looking in $dir\n"; File::Find::find({wanted => \&wanted}, $dir); foreach my $rpm (@rpms){ my $rpmname = `rpm --queryformat "%{NAME}%{ARCH}" -qp $rpm`; # print "$rpm -> $rpmname\n"; if($rpmkeys{$rpmname}){ my @b1 = split('/',$rpmkeys{$rpmname}); my @b2 = split('/',$rpm); if (!($b1[$#b1] eq $b2[$#b2])){ push(@delete,$b1[$#b1]); } } $rpmkeys{$rpmname} = $rpm; } } foreach my $del (@delete){ print "deleting $DESTDIR/RedHat/RPMS/$del\n"; unlink ("$DESTDIR/RedHat/RPMS/$del") || warn "$! $DESTDIR/RedHat/RPMS/$del\n"; } my $cmd = "rsync -v "; foreach my $rpmcp (keys(%rpmkeys)){ # print "$rpmcp -> $rpmkeys{$rpmcp}\n"; # print "$rpmkeys{$rpmcp}\n"; $cmd = $cmd . $rpmkeys{$rpmcp} . " "; } $cmd = $cmd . "$DESTDIR/RedHat/RPMS/"; #print "$cmd\n"; my $ret; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "rsync -aLv $SGIROOT/images $SGIROOT/dosutils $DESTDIR/"; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "rsync -aLv --exclude hdlist $SGIROOT/RedHat/base $DESTDIR/RedHat/"; $ret = system($cmd); #print "Ret $ret $cmd\n"; $cmd = "$genhdlist --withnumbers $DESTDIR"; $ret = system($cmd); print "Ret $ret $cmd\n"; sub wanted { /^.*\.rpm\z/s && push @rpms,$name; } --------------97265A97C78693C57B224BD1-- From owner-linux-xfs@oss.sgi.com Thu Jan 18 06:10:18 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 06:10:09 -0800 Received: from barock.informatik.uni-stuttgart.de ([129.69.215.70]:1028 "EHLO barock.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 06:09:56 -0800 Received: (from magallon@localhost) by barock.informatik.uni-stuttgart.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f0IDdWd01347 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 14:39:32 +0100 Date: Thu, 18 Jan 2001 14:39:32 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Can't get initial console Message-ID: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i X-Operating-System: Linux barock 2.2.16 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I'm having a problem as of late with our XFS test box (and I haven't had the time to take a look at it until today). The kernel boots, mounts the root partition (XFS) and tries to open the initial console and fails. If I pass the rw parameter to the kernel, it's able to get an initial console, eventually the root filesystem gets remounted ro and the boot fails (this is probably a problem in the SuSE boot scripts). This started happening arround the time 2.4.0 was checked in. At the moment I'm working my way thru this: kernel-2.4.0-XFS-test13-pre3+athlon.20001228.tar.gz kernel-2.4.0-XFS-test13-pre3+athlon.20001229.tar.gz kernel-2.4.0-XFS-test13-pre3+athlon.20001230.tar.gz kernel-2.4.0-XFS-test13-pre3+athlon.20001231.tar.gz kernel-2.4.0-XFS-test13-pre3+athlon.20010101.tar.gz kernel-2.4.0-XFS-test13-pre3+athlon.20010102.tar.gz kernel-2.4.0-XFS-prerelease+athlon.20010103.tar.gz kernel-2.4.0-XFS-prerelease+athlon.20010104.tar.gz kernel-2.4.0-XFS+athlon.20010106.tar.gz kernel-2.4.0-XFS+athlon.20010107.tar.gz kernel-2.4.0-XFS+athlon.20010108.tar.gz kernel-2.4.0-XFS+athlon.20010109.tar.gz kernel-2.4.0-XFS+athlon.20010110.tar.gz kernel-2.4.0-XFS+athlon.20010111.tar.gz kernel-2.4.0-XFS+athlon.20010112.tar.gz kernel-2.4.0-XFS+athlon.20010113.tar.gz kernel-2.4.0-XFS+athlon.20010114.tar.gz kernel-2.4.0-XFS+athlon.20010115.tar.gz kernel-2.4.0-XFS+athlon.20010116.tar.gz kernel-2.4.0-XFS+athlon.20010118.tar.gz (the missing builds are due to problems in the box that actually builds the kernels) Has anyone else seen this? TIA, -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:01:19 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:01:09 -0800 Received: from garnet.sover.net ([209.198.87.53]:4596 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:00:53 -0800 Received: from [192.168.1.3] (pm1a3.stj.sover.net [209.198.94.3]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id JAA06747; Thu, 18 Jan 2001 09:59:57 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a3.stj.sover.net [209.198.94.3] 209.198.94.3 Thu, 18 Jan 2001 09:59:57 -0500 (EST) Date: Thu, 18 Jan 2001 10:00:33 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello Marcelo, Personally, i just did the CVS thing and I have been using it since 2.4.0test10. Perhaps you might try that? What version of modutils, etc are on the box booting the kernel? As you probobly know, 2.4 requires newer versions of several packages. Have you tried a plain 2.4 kernel on it and seeing if you had the same problem? Also, what about the box you are building on? There are requirements for compiling the kernel, the most notable and the one that got me stuck, was the right compiler. you *have* to use gcc 2.95.2 nothing newer, nothing older :) the kernel wouldn't even build with the compiler I had installed (some newer compiler..Debian/Sid) To be honest it sounds like you might need to upgrade some of the packages on your test box, but that's just a hunch. /usr/src/linux/Documentation/Changes has all that info. That's al the help I can offer, I am not a developer, just someone insane enough to have a beta kernel with a beta OS, on a beta fs ;) Hope this helped! Jason Walker/RegEx On Thu, 18 Jan 2001, Marcelo E. Magallon wrote: > Hi, > > I'm having a problem as of late with our XFS test box (and I haven't > had the time to take a look at it until today). The kernel boots, > mounts the root partition (XFS) and tries to open the initial console > and fails. If I pass the rw parameter to the kernel, it's able to get > an initial console, eventually the root filesystem gets remounted ro > and the boot fails (this is probably a problem in the SuSE boot > scripts). This started happening arround the time 2.4.0 was checked > in. At the moment I'm working my way thru this: > > kernel-2.4.0-XFS-test13-pre3+athlon.20001228.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001229.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001230.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001231.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010101.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010102.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010103.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010104.tar.gz > kernel-2.4.0-XFS+athlon.20010106.tar.gz > kernel-2.4.0-XFS+athlon.20010107.tar.gz > kernel-2.4.0-XFS+athlon.20010108.tar.gz > kernel-2.4.0-XFS+athlon.20010109.tar.gz > kernel-2.4.0-XFS+athlon.20010110.tar.gz > kernel-2.4.0-XFS+athlon.20010111.tar.gz > kernel-2.4.0-XFS+athlon.20010112.tar.gz > kernel-2.4.0-XFS+athlon.20010113.tar.gz > kernel-2.4.0-XFS+athlon.20010114.tar.gz > kernel-2.4.0-XFS+athlon.20010115.tar.gz > kernel-2.4.0-XFS+athlon.20010116.tar.gz > kernel-2.4.0-XFS+athlon.20010118.tar.gz > > (the missing builds are due to problems in the box that actually builds > the kernels) > > Has anyone else seen this? > > TIA, > > -- > Marcelo > From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:01:48 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:01:28 -0800 Received: from barock.informatik.uni-stuttgart.de ([129.69.215.70]:1540 "EHLO barock.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:01:18 -0800 Received: (from magallon@localhost) by barock.informatik.uni-stuttgart.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f0IEUuP01562 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 15:30:56 +0100 Date: Thu, 18 Jan 2001 15:30:56 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010118153056.A1536@barock.informatik.uni-stuttgart.de> References: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <20010118143932.A1292@barock.informatik.uni-stuttgart.de>; from marcelo.magallon@bigfoot.com on Thu, Jan 18, 2001 at 02:39:32PM +0100 X-Operating-System: Linux barock 2.2.16 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> "Marcelo E. Magallon" writes: > kernel-2.4.0-XFS+athlon.20010110.tar.gz > kernel-2.4.0-XFS+athlon.20010111.tar.gz The image built on 2001-01-10 boots, the next one doesn't. Check out time is ~ 04:00 GMT. I'm looking at the changes right now, but I can't spot anything obvious. -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:03:39 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:03:18 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:23817 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:03:05 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id QAA26452 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 16:01:28 +0100 Date: Thu, 18 Jan 2001 16:01:28 +0100 From: sooo lame To: linux-xfs@oss.sgi.com Subject: XFS and badblocks(TM) Message-ID: <20010118160128.C19680@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, How XFS reacts while trying to read from damaged area (i.e. bad blocks on hard drive)? One of my disks unfortunately got bad sectors and XFS reaction was: "Kernel Panic" (as far as i know it's normal reaction - the journalling fs idea does _not_ handle with damaged block devices) .... What would be the best way to got the data (not on the damaged area) back? - Krzysztof PS. that "panic" is reproducable on particular file... From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:06:08 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:05:48 -0800 Received: from garnet.sover.net ([209.198.87.53]:42747 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:05:32 -0800 Received: from [192.168.1.3] (pm1a3.stj.sover.net [209.198.94.3]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id KAA10484; Thu, 18 Jan 2001 10:05:03 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a3.stj.sover.net [209.198.94.3] 209.198.94.3 Thu, 18 Jan 2001 10:05:03 -0500 (EST) Date: Thu, 18 Jan 2001 10:05:55 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I am profusely sorry. I meant you have to use egcs 1.1.2/gcc 2.91.66. Totally my mistake. sorry for the spam :P RegEx From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:19:08 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:18:59 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20854 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:18:39 -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 HAA09564 for ; Thu, 18 Jan 2001 07:27:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA505139; Thu, 18 Jan 2001 09:17:20 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14488; Thu, 18 Jan 2001 09:17:20 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IFICC22402; Thu, 18 Jan 2001 09:18:12 -0600 Message-Id: <200101181518.f0IFICC22402@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from "Marcelo E. Magallon" of "Thu, 18 Jan 2001 14:39:32 +0100." <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Date: Thu, 18 Jan 2001 09:18:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, Are you using devfs? I have seen problems with console access related to devfs - although in my case the failed to get initial console happened when I did not configure devfs. Also, where are the athlon patches coming from - they are nothing we distribute. If you can I would take the latest cvs tree as your starting point, and check the config options carefully. An alternate starting point would be the latest kernel source RPM ftp://oss.sgi.com/projects/xfs/download/XFS-RH7.0-rpms/kernel-source-2.4.0-SGI_XFS_PR.i386.rpm although this would entail more work getting all the code into a single tree. Steve > Hi, > > I'm having a problem as of late with our XFS test box (and I haven't > had the time to take a look at it until today). The kernel boots, > mounts the root partition (XFS) and tries to open the initial console > and fails. If I pass the rw parameter to the kernel, it's able to get > an initial console, eventually the root filesystem gets remounted ro > and the boot fails (this is probably a problem in the SuSE boot > scripts). This started happening arround the time 2.4.0 was checked > in. At the moment I'm working my way thru this: > > kernel-2.4.0-XFS-test13-pre3+athlon.20001228.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001229.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001230.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001231.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010101.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010102.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010103.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010104.tar.gz > kernel-2.4.0-XFS+athlon.20010106.tar.gz > kernel-2.4.0-XFS+athlon.20010107.tar.gz > kernel-2.4.0-XFS+athlon.20010108.tar.gz > kernel-2.4.0-XFS+athlon.20010109.tar.gz > kernel-2.4.0-XFS+athlon.20010110.tar.gz > kernel-2.4.0-XFS+athlon.20010111.tar.gz > kernel-2.4.0-XFS+athlon.20010112.tar.gz > kernel-2.4.0-XFS+athlon.20010113.tar.gz > kernel-2.4.0-XFS+athlon.20010114.tar.gz > kernel-2.4.0-XFS+athlon.20010115.tar.gz > kernel-2.4.0-XFS+athlon.20010116.tar.gz > kernel-2.4.0-XFS+athlon.20010118.tar.gz > > (the missing builds are due to problems in the box that actually builds > the kernels) > > Has anyone else seen this? > > TIA, > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:34:49 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:34:38 -0800 Received: from [209.101.91.34] ([209.101.91.34]:41990 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:34:29 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id LAA06067 for ; Thu, 18 Jan 2001 11:47:05 -0500 Message-ID: <3A670EC7.3B7A91AB@compro.net> Date: Thu, 18 Jan 2001 10:41:59 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Newbie wanting to try it out Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, I'm running SuSE linux 6.4 with kernel 2.4.0_SuSE which is basicly the released 2.4.0 kernel with patches for the resier filesystem. I'm not happy with this file system. It looks so far that if I want to try XFS that I have to use the kernel which is supplied with it from sgi. I'm a little hesitant to do this as it doesn't appear to be the released(final) version of the 2.4.0 kernel. Is there a package that can be added to the kernel that I already have? Or even one that is compatable with the released 2.4.0 kernel. I would really like to try XFS. Or maybe I'm way off base and the kernel version from the download site IS 2.4.0(final)? Thanks in advance. -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:52:39 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:52:28 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:30476 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:52:02 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id QAA03293; Thu, 18 Jan 2001 16:50:18 +0100 Date: Thu, 18 Jan 2001 16:50:18 +0100 From: sooo lame To: Mark Hounschell Cc: linux-xfs@oss.sgi.com Subject: Re: Newbie wanting to try it out Message-ID: <20010118165018.A510@main.braxis.co.uk> References: <3A670EC7.3B7A91AB@compro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A670EC7.3B7A91AB@compro.net>; from markh@compro.net on Thu, Jan 18, 2001 at 10:41:59AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, You should download 2.4.0 (final) XFS equipped from SGI's CVS repository. You'll find instructions on http://oss.sgi.com/projects/xfs/ Unfortunately XFS web page is outta date and ftp site AFAIR - also :( You'll find CVS on ftp://ftp.cvshome.org/pub/ - Krzysztof From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:54:09 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:53:48 -0800 Received: from barock.informatik.uni-stuttgart.de ([129.69.215.70]:5636 "EHLO barock.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:53:42 -0800 Received: (from magallon@localhost) by barock.informatik.uni-stuttgart.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f0IFNKF01918 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 16:23:20 +0100 Date: Thu, 18 Jan 2001 16:23:20 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010118162320.A1606@barock.informatik.uni-stuttgart.de> References: <200101181518.f0IFICC22402@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200101181518.f0IFICC22402@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 18, 2001 at 09:18:11AM -0600 X-Operating-System: Linux barock 2.2.16 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Steve Lord writes: > Are you using devfs? I have seen problems with console access related > to devfs - although in my case the failed to get initial console > happened when I did not configure devfs. No, I don't have devfs enabled. > Also, where are the athlon patches coming from - they are nothing we > distribute. Oh, I'm sorry about that. It's just a tag I use to avoid installing a kernel compiled for an Athlon on a Pentium box. > If you can I would take the latest cvs tree as your starting point, > and check the config options carefully. Yeah, the last tree I checked out won't boot either. On the configuration I have virtual terminals, the console is on a virtual terminal, unix98 pty support is compiled in, as well as /dev/pts support. As I said on another email, the image compile on 2001-01-10 boots, the one from the next day doesn't. There are some changes between the two dates in the IDE layer (the machine does have IDE disks) but I don't know the code well enough to make out what the changes imply without reading more. Thanks for the suggestions, -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 07:56:48 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 07:56:39 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:22024 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 07:56:25 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA04985 for ; Thu, 18 Jan 2001 07:56:22 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA505998; Thu, 18 Jan 2001 09:55:07 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA16135; Thu, 18 Jan 2001 09:55:07 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IFtwA22564; Thu, 18 Jan 2001 09:55:58 -0600 Message-Id: <200101181555.f0IFtwA22564@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: markh@compro.net cc: Linux-XFS Subject: Re: Newbie wanting to try it out In-Reply-To: Message from Mark Hounschell of "Thu, 18 Jan 2001 10:41:59 EST." <3A670EC7.3B7A91AB@compro.net> Date: Thu, 18 Jan 2001 09:55:58 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello, I'm running SuSE linux 6.4 with kernel 2.4.0_SuSE which is > basicly > the released 2.4.0 kernel with patches for the resier filesystem. I'm > not > happy with this file system. It looks so far that if I want to try XFS > that I have to use the kernel which is supplied with it from sgi. I'm a > little hesitant to do this as it doesn't appear to be the > released(final) > version of the 2.4.0 kernel. Is there a package that can be added to the > kernel that I already have? Or even one that is compatable with the > released 2.4.0 kernel. I would really like to try XFS. Or maybe I'm way > off base and the kernel version from the download site IS 2.4.0(final)? We do have the 2.4 kernel with XFS support. The cvs tree is setup this way, this is the fastest way to get changes. I just looked at what we have for ftp download, and it is somewhat redhat centric right now (nothing but rpms), however, you could take the kernel source rpm and do an rpm -bp on it to get a source tree, from this you could feed it your kernel config parameters (plus xfs options of course - you need to turn on experimental options for this to be an option) I think the source rpm you should start with - should you go that route is ftp://oss.sgi.com/projects/xfs/download/SGI-XFS_PR-test1/SRPMS/kernel-2.4.0-SGI_XFS_PR.src.rpm Once 2.4.1 is out and we have merged up to it then our tree will actually have reiserfs and xfs - at the moment you would have to use different kernels to move data out of reiserfs and into xfs - or you could apply a reiserfs patch to our kernel if you are feeling really brave. Steve > > Thanks in advance. > > -- > Mark Hounschell > markh@compro.net From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:03:08 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:02:49 -0800 Received: from garnet.sover.net ([209.198.87.53]:36309 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:02:47 -0800 Received: from [192.168.1.3] (pm1a3.stj.sover.net [209.198.94.3]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id LAA23765; Thu, 18 Jan 2001 11:02:06 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a3.stj.sover.net [209.198.94.3] 209.198.94.3 Thu, 18 Jan 2001 11:02:06 -0500 (EST) Date: Thu, 18 Jan 2001 11:02:52 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Mark Hounschell cc: Linux-XFS Subject: Re: Newbie wanting to try it out In-Reply-To: <3A670EC7.3B7A91AB@compro.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Mark, The CVS tree is currently at 2.4.0. Perhaos you could use that. I have not used the CVS snapshots, so I don't know what version they are at now. the cvs tree is the userspace tools *and* a XFS-patched kernel source tree. that makes life easy. Out of curiosity, what about reiser didn't you like? I ran it for many months without a hitch, however, the recovery times seemed a bit long at times, and they didn't come out with patches consistantly/fast enough. the XFS developers have been *very* good at keeping on top of that, of which I am very impressed (XFS developers reading this: THANKS GUYS! :) have fun moving from reiser to XFS :) Jason Walker / RegEx On Thu, 18 Jan 2001, Mark Hounschell wrote: > Hello, I'm running SuSE linux 6.4 with kernel 2.4.0_SuSE which is > basicly > the released 2.4.0 kernel with patches for the resier filesystem. I'm > not > happy with this file system. It looks so far that if I want to try XFS > that I have to use the kernel which is supplied with it from sgi. I'm a > little hesitant to do this as it doesn't appear to be the > released(final) > version of the 2.4.0 kernel. Is there a package that can be added to the > kernel that I already have? Or even one that is compatable with the > released 2.4.0 kernel. I would really like to try XFS. Or maybe I'm way > off base and the kernel version from the download site IS 2.4.0(final)? > > Thanks in advance. > > -- > Mark Hounschell > markh@compro.net > From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:06:58 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:06:40 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:36979 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:06:28 -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 IAA29652 for ; Thu, 18 Jan 2001 08:05:28 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA505671; Thu, 18 Jan 2001 10:05:06 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA15773; Thu, 18 Jan 2001 10:05:06 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IG5vk22584; Thu, 18 Jan 2001 10:05:57 -0600 Message-Id: <200101181605.f0IG5vk22584@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Marcelo E. Magallon" cc: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from "Marcelo E. Magallon" of "Thu, 18 Jan 2001 16:23:20 +0100." <20010118162320.A1606@barock.informatik.uni-stuttgart.de> Date: Thu, 18 Jan 2001 10:05:57 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > >> Steve Lord writes: > > > Are you using devfs? I have seen problems with console access related > > to devfs - although in my case the failed to get initial console > > happened when I did not configure devfs. > > No, I don't have devfs enabled. > > > Also, where are the athlon patches coming from - they are nothing we > > distribute. > > Oh, I'm sorry about that. It's just a tag I use to avoid installing a > kernel compiled for an Athlon on a Pentium box. > > > If you can I would take the latest cvs tree as your starting point, > > and check the config options carefully. > > Yeah, the last tree I checked out won't boot either. On the > configuration I have virtual terminals, the console is on a virtual > terminal, unix98 pty support is compiled in, as well as /dev/pts > support. > > As I said on another email, the image compile on 2001-01-10 boots, the > one from the next day doesn't. There are some changes between the two > dates in the IDE layer (the machine does have IDE disks) but I don't > know the code well enough to make out what the changes imply without > reading more. This may be your problem - I think IDE had some bad days, have you tried stuff beyond this date, or are you in the process of narrowing down when it broke? Steve > > Thanks for the suggestions, > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:19:59 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:19:39 -0800 Received: from [209.101.91.34] ([209.101.91.34]:61190 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:19:11 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id MAA06285 for ; Thu, 18 Jan 2001 12:31:47 -0500 Message-ID: <3A671941.2F67DE13@compro.net> Date: Thu, 18 Jan 2001 11:26:41 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Re: Newbie wanting to try it out References: <3A670EC7.3B7A91AB@compro.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thanks all. I'll be giving it a try asap. -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:28:28 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:28:19 -0800 Received: from [209.101.91.34] ([209.101.91.34]:64006 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:28:05 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id MAA06302; Thu, 18 Jan 2001 12:40:42 -0500 Message-ID: <3A671B58.876F1DE@compro.net> Date: Thu, 18 Jan 2001 11:35:36 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Walker CC: Linux-XFS Subject: Re: Newbie wanting to try it out References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jason Walker wrote: > > Mark, > Out of curiosity, what about reiser didn't you like? I used the reiser fs mainly for music. Something about what I was doing with the music (converting, recording, playing, etc) kept crashing the fs. And I was not able to recover except for backups. This happened 2 times so I finally went back to ext2 and never had another problem. Ext2 takes quite a long time to go through a fsck on a 45GB partition let alone a couple of them. We use sgi's xfs here at work on sgi boxes and I was very impressed with it. It's probably the best there is. Just though I'd like to try it out on my linux box. -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:55:09 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:54:59 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:28450 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:54:40 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08627 for ; Thu, 18 Jan 2001 08:54:37 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA506761; Thu, 18 Jan 2001 10:53:22 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA19076; Thu, 18 Jan 2001 10:53:22 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IGsC922715; Thu, 18 Jan 2001 10:54:13 -0600 Message-Id: <200101181654.f0IGsC922715@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: sooo lame cc: linux-xfs@oss.sgi.com Subject: Re: XFS and badblocks(TM) In-Reply-To: Message from sooo lame of "Thu, 18 Jan 2001 16:01:28 +0100." <20010118160128.C19680@main.braxis.co.uk> Date: Thu, 18 Jan 2001 10:54:12 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hi, > > How XFS reacts while trying to read from damaged area > (i.e. bad blocks on hard drive)? One of my disks > unfortunately got bad sectors and XFS reaction was: > "Kernel Panic" (as far as i know it's normal reaction > - the journalling fs idea does _not_ handle with > damaged block devices) .... What would be the best > way to got the data (not on the damaged area) back? > > - Krzysztof > > PS. > that "panic" is reproducable on particular file... This discussion just came up internally yesterday, XFS was originally written on a system where bad block handling was totally below the filesystem, as it is on almost everything now. The final result should not be a kernel panic, but for the filesystem to shut itself down, this is not working yet though. However, that aside, it rather depends on what XFS had living on the bad blocks, from the sound of it it appears to be metadata. You say the panic is related to a particular file - do you need contents of this file, or the rest of the filesystem, also, is the error related to looking at the inode (ls does it) or contents (cat does it)? If the panic was restricted to this file then you could copy off the rest of the filesystem and avoid this one. If you want the contents of the file things get harder - we would need to see the panic and where it is coming from - it may be possible to modify the kernel a little bit to just ignore the error and carry on, it depends on what it is. Steve From owner-linux-xfs@oss.sgi.com Thu Jan 18 08:59:09 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 08:58:59 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:28196 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 08:58:46 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA02668 for ; Thu, 18 Jan 2001 08:58:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA506564 for ; Thu, 18 Jan 2001 10:57:29 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA20890 for ; Thu, 18 Jan 2001 10:57:29 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0IGwKe22918; Thu, 18 Jan 2001 10:58:20 -0600 Message-Id: <200101181658.f0IGwKe22918@jen.americas.sgi.com> Date: Thu, 18 Jan 2001 10:58:20 -0600 Subject: TAKE - remove experimental tag from xfs config options To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing In Linux terms XFS has moved out of the 'experimental' software stage. Date: Thu Jan 18 08:56:36 PST 2001 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:82496a linux/fs/Config.in - 1.50 - Remove the experimental tag from xfs - we have come bit beyond that now. From owner-linux-xfs@oss.sgi.com Thu Jan 18 09:00:39 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 09:00:29 -0800 Received: from mail11.jump.net ([206.196.91.11]:5835 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 09:00:12 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0IH0BQ27650 for ; Thu, 18 Jan 2001 11:00:11 -0600 (CST) Message-ID: <3A67211E.D9DF284@sgi.com> Date: Thu, 18 Jan 2001 11:00:14 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-prerelease i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console References: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> <20010118153056.A1536@barock.informatik.uni-stuttgart.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I think we may have seen something similar when we were building some kernel RPMs... Russel - on our installer, we had one kernel that gave us the "initial console" problem. You thought it was a DevFS problem, I swore up and down that DevFS was turned off. I think you just recompiled the SRPM on your box and the problem went away - so could it be compiler related? -Eric "Marcelo E. Magallon" wrote: > > >> "Marcelo E. Magallon" writes: > > > kernel-2.4.0-XFS+athlon.20010110.tar.gz > > kernel-2.4.0-XFS+athlon.20010111.tar.gz > > The image built on 2001-01-10 boots, the next one doesn't. Check out > time is ~ 04:00 GMT. I'm looking at the changes right now, but I can't > spot anything obvious. > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 09:36:30 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 09:36:19 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:60306 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 09:35:59 -0800 Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id SAA14319 for ; Thu, 18 Jan 2001 18:34:03 +0100 (MET) Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.11.0/2.2) id f0IHZuP06094 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 18:35:56 +0100 Date: Thu, 18 Jan 2001 18:35:55 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010118183555.A5796@techno.informatik.uni-stuttgart.de> Mail-Followup-To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com References: <200101181605.f0IG5vk22584@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200101181605.f0IG5vk22584@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 18, 2001 at 10:05:57AM -0600 X-Operating-System: Linux techno 2.4.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Steve Lord writes: > This may be your problem - I think IDE had some bad days, have you > tried stuff beyond this date, or are you in the process of narrowing > down when it broke? Yes, just finished trying all the builds I have between the 10th and today, and no, none of them will boot, and I haven't seen anything like this on lkml, so I thought this was somehow specific to the XFS tree. I'll go read some more code, -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 09:52:49 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 09:52:29 -0800 Received: from Cantor.suse.de ([194.112.123.193]:24333 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 18 Jan 2001 09:52:13 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id B28411E1BB; Thu, 18 Jan 2001 18:52:11 +0100 (MET) Date: Thu, 18 Jan 2001 18:52:06 +0100 From: Andi Kleen To: Steve Lord Cc: markh@compro.net, Linux-XFS Subject: Re: Newbie wanting to try it out Message-ID: <20010118185206.A29886@gruyere.muc.suse.de> References: <200101181555.f0IFtwA22564@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: <200101181555.f0IFtwA22564@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 18, 2001 at 09:55:58AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Thu, Jan 18, 2001 at 09:55:58AM -0600, Steve Lord wrote: > > Hello, I'm running SuSE linux 6.4 with kernel 2.4.0_SuSE which is > > basicly > > the released 2.4.0 kernel with patches for the resier filesystem. I'm > > not > > happy with this file system. It looks so far that if I want to try XFS > > that I have to use the kernel which is supplied with it from sgi. I'm a > > little hesitant to do this as it doesn't appear to be the > > released(final) > > version of the 2.4.0 kernel. Is there a package that can be added to the > > kernel that I already have? Or even one that is compatable with the > > released 2.4.0 kernel. I would really like to try XFS. Or maybe I'm way > > off base and the kernel version from the download site IS 2.4.0(final)? > > We do have the 2.4 kernel with XFS support. The cvs tree is setup > this way, this is the fastest way to get changes. I just looked at > what we have for ftp download, and it is somewhat redhat centric > right now (nothing but rpms), however, you could take the kernel > source rpm and do an rpm -bp on it to get a source tree, from this > you could feed it your kernel config parameters (plus xfs options > of course - you need to turn on experimental options for this to > be an option) Just a warning. Newer SuSE ships with gcc 2.95, which unfortunately miscompiles xfs. You need to copy an egcs 1.1 from an older suse release and compile the kernel with that. > Once 2.4.1 is out and we have merged up to it then our tree will actually > have reiserfs and xfs - at the moment you would have to use different > kernels to move data out of reiserfs and into xfs - or you could apply > a reiserfs patch to our kernel if you are feeling really brave. It'll be interesting to see comparable benchmarks when that happens. On my first not totally scientific tests reiserfs seems to be faster than XFS on metadata write performance (rm -rf of big trees, untar of tars with lots of files) -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 18 10:12:19 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 10:12:00 -0800 Received: from justice.loyola.edu ([144.126.178.227]:17925 "EHLO justice.loyola.edu") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 10:11:28 -0800 Received: (from mstone@localhost) by justice.loyola.edu (8.9.3/8.9.3/Debian 8.9.3-21) id NAA30579 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 13:11:13 -0500 Date: Thu, 18 Jan 2001 13:11:13 -0500 From: Michael Stone To: linux-xfs@oss.sgi.com Subject: Re: Newbie wanting to try it out Message-ID: <20010118131113.D686@justice.loyola.edu> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing FWIW, I think it would be a lot easier (read: more people would do it) to try xfs if there were a simple patch available. Downloading the whole kernel (again, since most people already have one) seems wasteful, and cvs is fairly slow/inefficent. -- Mike Stone From owner-linux-xfs@oss.sgi.com Thu Jan 18 10:24:49 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 10:24:39 -0800 Received: from garnet.sover.net ([209.198.87.53]:34289 "EHLO garnet.sover.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 10:24:12 -0800 Received: from [192.168.1.3] (pm1a30.stj.sover.net [209.198.94.30]) by garnet.sover.net (8.9.3/8.9.3) with ESMTP id NAA07643; Thu, 18 Jan 2001 13:24:07 -0500 (EST) Comments: SoVerNet Verification (on garnet.sover.net) [192.168.1.3] from pm1a30.stj.sover.net [209.198.94.30] 209.198.94.30 Thu, 18 Jan 2001 13:24:07 -0500 (EST) Date: Thu, 18 Jan 2001 13:24:54 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Michael Stone cc: linux-xfs@oss.sgi.com Subject: Re: Newbie wanting to try it out In-Reply-To: <20010118131113.D686@justice.loyola.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS is still Beta last I heard. that means newbies and the uninclined shouldn't be using it. I think that works out very well, kinda wards them off. oh, and last I checked there were patches available. Jason Walker/RegEx On Thu, 18 Jan 2001, Michael Stone wrote: > FWIW, I think it would be a lot easier (read: more people would do it) > to try xfs if there were a simple patch available. Downloading the whole > kernel (again, since most people already have one) seems wasteful, and > cvs is fairly slow/inefficent. > > -- > Mike Stone > From owner-linux-xfs@oss.sgi.com Thu Jan 18 10:35:49 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 10:35:40 -0800 Received: from pD901E367.dip.t-dialin.net ([217.1.227.103]:8621 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 10:35:21 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f0IIqQs28960; Thu, 18 Jan 2001 19:52:26 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 18 Jan 2001 19:52:26 +0100 From: utz lehmann To: "Marcelo E. Magallon" Cc: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010118195226.A28945@s2y4n2c.de> References: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010118143932.A1292@barock.informatik.uni-stuttgart.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi i have the same problem: Start mounting filesystem: ide0(3,6) Ending clean XFS mount for filesystem: ide0(3,6) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 200k freed Warning: unable to open an initial console. this happens with console on VT or serial. i use ide disks. the same kernel boots on a ext2 root partition without problems (lilo: root=/dev/hda4). the xfs root fs is mountable und xfs_check reports no errors. hope that helps. utz lehmann Marcelo E. Magallon [marcelo.magallon@bigfoot.com] wrote: > Hi, > > I'm having a problem as of late with our XFS test box (and I haven't > had the time to take a look at it until today). The kernel boots, > mounts the root partition (XFS) and tries to open the initial console > and fails. If I pass the rw parameter to the kernel, it's able to get > an initial console, eventually the root filesystem gets remounted ro > and the boot fails (this is probably a problem in the SuSE boot > scripts). This started happening arround the time 2.4.0 was checked > in. At the moment I'm working my way thru this: > > kernel-2.4.0-XFS-test13-pre3+athlon.20001228.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001229.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001230.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20001231.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010101.tar.gz > kernel-2.4.0-XFS-test13-pre3+athlon.20010102.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010103.tar.gz > kernel-2.4.0-XFS-prerelease+athlon.20010104.tar.gz > kernel-2.4.0-XFS+athlon.20010106.tar.gz > kernel-2.4.0-XFS+athlon.20010107.tar.gz > kernel-2.4.0-XFS+athlon.20010108.tar.gz > kernel-2.4.0-XFS+athlon.20010109.tar.gz > kernel-2.4.0-XFS+athlon.20010110.tar.gz > kernel-2.4.0-XFS+athlon.20010111.tar.gz > kernel-2.4.0-XFS+athlon.20010112.tar.gz > kernel-2.4.0-XFS+athlon.20010113.tar.gz > kernel-2.4.0-XFS+athlon.20010114.tar.gz > kernel-2.4.0-XFS+athlon.20010115.tar.gz > kernel-2.4.0-XFS+athlon.20010116.tar.gz > kernel-2.4.0-XFS+athlon.20010118.tar.gz > > (the missing builds are due to problems in the box that actually builds > the kernels) > > Has anyone else seen this? > > TIA, > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 10:42:30 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 10:42:19 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:54104 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 10:42:10 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA09307 for ; Thu, 18 Jan 2001 10:42:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA507677; Thu, 18 Jan 2001 12:40:51 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA38678; Thu, 18 Jan 2001 12:40:51 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IIff623189; Thu, 18 Jan 2001 12:41:41 -0600 Message-Id: <200101181841.f0IIff623189@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: utz lehmann cc: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from utz lehmann of "Thu, 18 Jan 2001 19:52:26 +0100." <20010118195226.A28945@s2y4n2c.de> Date: Thu, 18 Jan 2001 12:41:41 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > hi > > i have the same problem: OK I am going back to try and reproduce this here, I think I know how to I was building the kernel when I hit it. Steve > > Start mounting filesystem: ide0(3,6) > Ending clean XFS mount for filesystem: ide0(3,6) > VFS: Mounted root (xfs filesystem) readonly. > Freeing unused kernel memory: 200k freed > Warning: unable to open an initial console. > > this happens with console on VT or serial. > i use ide disks. > > the same kernel boots on a ext2 root partition without problems > (lilo: root=/dev/hda4). the xfs root fs is mountable und xfs_check > reports no errors. > > hope that helps. > > utz lehmann > > > > Marcelo E. Magallon [marcelo.magallon@bigfoot.com] wrote: > > Hi, > > > > I'm having a problem as of late with our XFS test box (and I haven't > > had the time to take a look at it until today). The kernel boots, > > mounts the root partition (XFS) and tries to open the initial console > > and fails. If I pass the rw parameter to the kernel, it's able to get > > an initial console, eventually the root filesystem gets remounted ro > > and the boot fails (this is probably a problem in the SuSE boot > > scripts). This started happening arround the time 2.4.0 was checked > > in. At the moment I'm working my way thru this: > > > > kernel-2.4.0-XFS-test13-pre3+athlon.20001228.tar.gz > > kernel-2.4.0-XFS-test13-pre3+athlon.20001229.tar.gz > > kernel-2.4.0-XFS-test13-pre3+athlon.20001230.tar.gz > > kernel-2.4.0-XFS-test13-pre3+athlon.20001231.tar.gz > > kernel-2.4.0-XFS-test13-pre3+athlon.20010101.tar.gz > > kernel-2.4.0-XFS-test13-pre3+athlon.20010102.tar.gz > > kernel-2.4.0-XFS-prerelease+athlon.20010103.tar.gz > > kernel-2.4.0-XFS-prerelease+athlon.20010104.tar.gz > > kernel-2.4.0-XFS+athlon.20010106.tar.gz > > kernel-2.4.0-XFS+athlon.20010107.tar.gz > > kernel-2.4.0-XFS+athlon.20010108.tar.gz > > kernel-2.4.0-XFS+athlon.20010109.tar.gz > > kernel-2.4.0-XFS+athlon.20010110.tar.gz > > kernel-2.4.0-XFS+athlon.20010111.tar.gz > > kernel-2.4.0-XFS+athlon.20010112.tar.gz > > kernel-2.4.0-XFS+athlon.20010113.tar.gz > > kernel-2.4.0-XFS+athlon.20010114.tar.gz > > kernel-2.4.0-XFS+athlon.20010115.tar.gz > > kernel-2.4.0-XFS+athlon.20010116.tar.gz > > kernel-2.4.0-XFS+athlon.20010118.tar.gz > > > > (the missing builds are due to problems in the box that actually builds > > the kernels) > > > > Has anyone else seen this? > > > > TIA, > > > > -- > > Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 11:01:10 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 11:00:59 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:11889 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 11:00: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 KAA14109 for ; Thu, 18 Jan 2001 10:59:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA508021; Thu, 18 Jan 2001 12:59:21 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA38801; Thu, 18 Jan 2001 12:59:21 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IJ0Bi23236; Thu, 18 Jan 2001 13:00:11 -0600 Message-Id: <200101181900.f0IJ0Bi23236@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Steve Lord cc: utz lehmann , "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from Steve Lord of "Thu, 18 Jan 2001 12:41:41 CST." <200101181841.f0IIff623189@jen.americas.sgi.com> Date: Thu, 18 Jan 2001 13:00:11 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > hi > > > > i have the same problem: > > OK I am going back to try and reproduce this here, I think I know how > to I was building the kernel when I hit it. Yep, this was very simple to hit, running with /dev inside of XFS appears to be part of it - I am running on an ide root, not sure how that factors in to it. I suspect a problem in dev handling inside XFS, so a workaround would be to run devfs with the mount at boot time option (ok I know that is not always an option) or a non-xfs /dev directory in some other way. If you have redhat 7 devfs is not actually painful to get going. Steve From owner-linux-xfs@oss.sgi.com Thu Jan 18 12:33:39 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 12:33:20 -0800 Received: from barry.mail.mindspring.net ([207.69.200.25]:29221 "EHLO barry.mail.mindspring.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 12:33:12 -0800 Received: from mindspring.com (user-38ld35d.dialup.mindspring.com [209.86.140.173]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA20513 for ; Thu, 18 Jan 2001 15:33:10 -0500 (EST) Message-ID: <3A675568.3821DE7D@mindspring.com> Date: Thu, 18 Jan 2001 15:43:20 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: XFS and RAID5 Aren't Playing Well Together (more info) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Howdy, again! As you may remember, Scott Smyth posted a plea for help here last week (or early this week), regarding XFS on RAID5. If an attempt to mount XFS on a RAID5 array while it's rebuilding is made, then the rebuild stops, as evidenced by the numbers in /proc/mdstat never changing. He asked me to work on this too, and I have some more insight to share. The function md_do_sync in md.c is the scheduling exec for raid5syncd. Around line 3353, a for loop is started. It calls raid5_sync_request (in raid5.c) who updates some number of blocks, and returns how many it updated in the blocks variable. During the failure, I've verified that blocks is 0! Thus, j (the loop index) is never increased, and it never exits. It also never reaches the 'md_signal_pending' call, which is consistent with my findings: kill(1) doesn't work on the runaway raid5syncd. Tracing back into raid5_sync_request, the last statement is: return (bufsize>>10)-redone; Now, bufsize comes from sh->size, which is the MD blocksize. I've noticed several times now, that kernel messages from raid5 regarding the bufsize changing to/from 512, 1024, and 4096 occur just before any oopsen/panics/crashes. If bufsize is really 512, then 512 >> 10 is 0! In fact, even with a 'clean' RAID5, in just copying a directory full of "The Allman Brothers" MP3s to my XFS on RAID5, these blocksize change messages occur several times, after which the kernel oops/panics/reboots. That last part is inconsistent. Hopefully, this isn't due to the content of the files ;-). Now my main question: why does XFS change the block size? Also, when I attempt the mkfs.xfs, md reports: "mkfs.xfs(pid 527) used obsolete MD ioctl, upgrade your software to use new ictls." Is this an attempt by mkfs.xfs to change the blocksize? Thanks for your time! -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Thu Jan 18 12:51:30 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 12:51:21 -0800 Received: from ns1.SuSE.com ([202.58.118.2]:15635 "HELO ns1.suse.com") by oss.sgi.com with SMTP id ; Thu, 18 Jan 2001 12:50:53 -0800 Received: from euclid.oak.suse.com (fw.SuSE.com [202.58.118.35]) by ns1.suse.com (Postfix) with ESMTP id 05A13DF91B; Thu, 18 Jan 2001 12:48:13 -0800 (PST) Received: from localhost (jsimmons@localhost) by euclid.oak.suse.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA00485; Thu, 18 Jan 2001 12:51:00 -0800 X-Authentication-Warning: euclid.oak.suse.com: jsimmons owned process doing -bs Date: Thu, 18 Jan 2001 12:51:00 -0800 (PST) From: James Simmons X-Sender: jsimmons@euclid.oak.suse.com To: utz lehmann Cc: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: <20010118195226.A28945@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > i have the same problem: > > Start mounting filesystem: ide0(3,6) > Ending clean XFS mount for filesystem: ide0(3,6) > VFS: Mounted root (xfs filesystem) readonly. > Freeing unused kernel memory: 200k freed > Warning: unable to open an initial console. > > this happens with console on VT or serial. Do you have /dev on the XFS partition? Most important you need /dev/console on that partition. From linux/init/main.c: /* * Ok, we have completed the initial bootup, and * we're essentially up and running. Get rid of the * initmem segments and start the user-mode stuff.. */ free_initmem(); unlock_kernel(); if (open("/dev/console", O_RDWR, 0) < 0) printk("Warning: unable to open an initial console.\n"); (void) dup(0); (void) dup(0); From owner-linux-xfs@oss.sgi.com Thu Jan 18 13:09:00 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 13:08:40 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:46121 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 13:08:15 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA09478 for ; Thu, 18 Jan 2001 13:08:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA510408; Thu, 18 Jan 2001 15:06:53 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA59237; Thu, 18 Jan 2001 15:06:53 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IL7gp23562; Thu, 18 Jan 2001 15:07:42 -0600 Message-Id: <200101182107.f0IL7gp23562@jen.americas.sgi.com> To: James Simmons cc: utz lehmann , "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-reply-to: References: Comments: In-reply-to James Simmons message dated "Thu, 18 Jan 2001 12:51:00 -0800." Date: Thu, 18 Jan 2001 15:07:42 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Right, the problem is that xfs does it's own permissions checking, and there is no special case for opening a device read/write on a readonly filesystem - which is what happens to the console at boot time. I am working on the fix, should be along shortly. Steve > > i have the same problem: > > > > Start mounting filesystem: ide0(3,6) > > Ending clean XFS mount for filesystem: ide0(3,6) > > VFS: Mounted root (xfs filesystem) readonly. > > Freeing unused kernel memory: 200k freed > > Warning: unable to open an initial console. > > > > this happens with console on VT or serial. > > Do you have /dev on the XFS partition? Most important you need > /dev/console on that partition. From linux/init/main.c: > > /* > * Ok, we have completed the initial bootup, and > * we're essentially up and running. Get rid of the > * initmem segments and start the user-mode stuff.. > */ > free_initmem(); > unlock_kernel(); > > if (open("/dev/console", O_RDWR, 0) < 0) > printk("Warning: unable to open an initial console.\n"); > > (void) dup(0); > (void) dup(0); > > From owner-linux-xfs@oss.sgi.com Thu Jan 18 13:11:40 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 13:11:30 -0800 Received: from pD901EDA0.dip.t-dialin.net ([217.1.237.160]:55470 "EHLO kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 13:11:21 -0800 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f0ILSgq30762; Thu, 18 Jan 2001 22:28:42 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 18 Jan 2001 22:28:42 +0100 From: utz lehmann To: Steve Lord Cc: utz lehmann , "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010118222842.A30741@s2y4n2c.de> References: <200101181920.f0IJK8t23420@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: <200101181920.f0IJK8t23420@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing hi it works. not mounting the root fs read only works too (without the patch). thanks. utz lehmann Steve Lord [lord@sgi.com] wrote: > OK, I have to go off the air for a while here, but I think the problem is > due to opening the console read/write before the filesystem is read/write, > a very basic work around would be to comment out this check: > > if ((mode & IWRITE) && !WRITEALLOWED(XFS_ITOV(ip))) > return XFS_ERROR(EROFS); > > at line 3486 of fs/xfs/xfs_inode.c > > This is a guess and is not the correct final solution. It all has to do > with xfs doing its own permission checks I think. Can someone try and > let me know. > > Steve > From owner-linux-xfs@oss.sgi.com Thu Jan 18 13:33:41 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 13:33:31 -0800 Received: from tux.mkp.net ([130.225.60.11]:17939 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 13:33:18 -0800 Received: from bentley.socsci.auc.dk ([130.225.60.48] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14JMfh-0003DJ-00; Thu, 18 Jan 2001 22:33:02 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id QAA07587; Thu, 18 Jan 2001 16:32:17 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: dcox@connex.com Cc: Linux-XFS Subject: Re: XFS and RAID5 Aren't Playing Well Together (more info) References: <3A675568.3821DE7D@mindspring.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 18 Jan 2001 16:32:17 -0500 In-Reply-To: <3A675568.3821DE7D@mindspring.com> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Danny" == Danny writes: Danny> Now my main question: why does XFS change the block size? Because some of our writes operate on smaller entities than the fs block size. Danny> Also, when I attempt the mkfs.xfs, md reports: "mkfs.xfs(pid Danny> 527) used obsolete MD ioctl, upgrade your software to use new Danny> ictls." Is this an attempt by mkfs.xfs to change the Danny> blocksize? Yep. My bug. It seems I never committed the BLKSETSIZE ioctl changes to md. Will run some tests before updating the tree... -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Thu Jan 18 13:53:11 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 13:53:01 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:14399 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 13:52:50 -0800 Received: from waco.engr.sgi.com ([163.154.18.95]) 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 NAA09778 for ; Thu, 18 Jan 2001 13:52:42 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f0ILpqX21877 for linux-xfs@oss.sgi.com; Thu, 18 Jan 2001 13:51:52 -0800 Date: Thu, 18 Jan 2001 13:51:52 -0800 From: Ananth Ananthanarayanan Message-Id: <200101182151.f0ILpqX21877@waco.engr.sgi.com> Subject: TAKE - allow deactivation of delalloc pages To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing One more incursion into the VM now not needed. Date: Thu Jan 18 13:45:22 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-delalloc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82524a linux/mm/swap.c - 1.7 - No special handling needed for delalloc on deactivate since deactivation moves pages to dirty list; page_launder knows not to touch the page until converted. From owner-linux-xfs@oss.sgi.com Thu Jan 18 14:37:22 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 14:37:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:14163 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 14:36:58 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAB07121 for ; Thu, 18 Jan 2001 14:36:56 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA511139 for ; Thu, 18 Jan 2001 16:35:41 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA59976 for ; Thu, 18 Jan 2001 16:35:41 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0IMarX01291; Thu, 18 Jan 2001 16:36:53 -0600 Message-Id: <200101182236.f0IMarX01291@jen.americas.sgi.com> Date: Thu, 18 Jan 2001 16:36:53 -0600 Subject: TAKE - change delalloc space conversion locking To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This removes a lock from the path which converts delayed allocate extents into real extents. It was previously obtaining the I/O lock in the xfs inode which it does not need to do (this was also going to cause problems with cxfs). This introduces VOP_STRATEGY, currently a misnomer since it does not do quite what it does in Irix, but there will probably be more changes to come later in this area. Also a pagebuf change to avoid calling balance_dirty when operating on a partial page - as there is the chance that some other part of the page could be in a buffer on the dirty queue and cause us to deadlock on the page lock. Date: Thu Jan 18 14:31:19 PST 2001 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:82528a linux/mm/vmscan.c - 1.45 linux/mm/page_alloc.c - 1.34 linux/mm/filemap.c - 1.64 - Wrap testing for delalloc page in a macro linux/include/linux/mm.h - 1.45 - define DelallocPage() macro linux/fs/buffer.c - 1.52 - Wrap testing for delalloc page in a macro linux/fs/xfs/xfs_vnodeops.c - 1.485 - Add xfs_strategy to vnode ops linux/fs/xfs/linux/xfs_lrw.h - 1.15 - prototype for xfs_strategy linux/fs/xfs/linux/xfs_lrw.c - 1.70 - Rework the code for converting dealloc to real space, add xfs_strategy to do this. linux/fs/xfs/linux/xfs_iops.c - 1.88 - Call VOP_STRATEGY instead of VOP_BMAP for delalloc space allocation calls. linux/fs/pagebuf/page_buf_io.c - 1.41 - Wrap testing for delalloc page in a macro, and do not call balance dirty in a case where we could have other I/O pending in the same page i.e. when doing a partial page operation. linux/fs/xfs/linux/xfs_vnode.h - 1.13 - Add VOP_STRATEGY From owner-linux-xfs@oss.sgi.com Thu Jan 18 17:50:53 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 17:50:43 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:57551 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 17:50:24 -0800 Received: from rock.informatik.uni-stuttgart.de (root@rock [129.69.215.43]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id CAA24257 for ; Fri, 19 Jan 2001 02:48:29 +0100 (MET) Received: (from magallon@localhost) by rock.informatik.uni-stuttgart.de (8.9.3/2.2) id CAA11363 for linux-xfs@oss.sgi.com; Fri, 19 Jan 2001 02:50:21 +0100 Date: Fri, 19 Jan 2001 02:50:21 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010119025021.A11358@rock.informatik.uni-stuttgart.de> Mail-Followup-To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com References: <20010118195226.A28945@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: ; from jsimmons@suse.com on Thu, Jan 18, 2001 at 12:51:00PM -0800 X-Operating-System: Linux rock 2.2.16 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> James Simmons writes: > if (open("/dev/console", O_RDWR, 0) < 0) Duh. I overlooked this the first time I looked at it. The root filesystem is mounted ro at this point, but it's trying to open /dev/console RDWR. -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 17:55:23 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 17:55:13 -0800 Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:208 "EHLO ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 17:55:04 -0800 Received: from rock.informatik.uni-stuttgart.de (root@rock [129.69.215.43]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id CAA24298 for ; Fri, 19 Jan 2001 02:53:10 +0100 (MET) Received: (from magallon@localhost) by rock.informatik.uni-stuttgart.de (8.9.3/2.2) id CAA11453 for linux-xfs@oss.sgi.com; Fri, 19 Jan 2001 02:55:01 +0100 Date: Fri, 19 Jan 2001 02:55:01 +0100 From: "Marcelo E. Magallon" To: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console Message-ID: <20010119025501.B11358@rock.informatik.uni-stuttgart.de> Mail-Followup-To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com References: <200101181900.f0IJ0Bi23236@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <200101181900.f0IJ0Bi23236@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 18, 2001 at 01:00:11PM -0600 X-Operating-System: Linux rock 2.2.16 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >> Steve Lord writes: > Yep, this was very simple to hit, running with /dev inside of XFS > appears to be part of it - I am running on an ide root, not sure how > that factors in to it. I suspect a problem in dev handling inside > XFS Might be. devfs "fixes" this because it's not mounted ro but rw. Now I have a general idea where the problem might be, I'll take a look tomorrow, I need to sleep now. Thanks, -- Marcelo From owner-linux-xfs@oss.sgi.com Thu Jan 18 18:00:13 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 17:59:53 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:11285 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 17:59: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 OAA14306 for ; Thu, 18 Jan 2001 14:02:29 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA510441 for ; Thu, 18 Jan 2001 16:02:10 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA15152 for ; Thu, 18 Jan 2001 16:02:09 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IM2wB30934; Thu, 18 Jan 2001 16:02:58 -0600 Message-Id: <200101182202.f0IM2wB30934@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Patch for cannot open initial console error Date: Thu, 18 Jan 2001 16:02:58 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is an untested patch which should fix the problem where an xfs root (specifically /dev directory) booted readonly leads to problems with opening the console device. It should follow the permissions checking behaviour of other filesystems. Steve =========================================================================== Index: linux/fs/xfs/linux/xfs_vnode.h =========================================================================== --- /usr/tmp/TmpDir.29187-0/linux/fs/xfs/linux/xfs_vnode.h_1.11 Thu Jan 18 15:53:33 2001 +++ linux/fs/xfs/linux/xfs_vnode.h Thu Jan 18 15:53:02 2001 @@ -703,8 +703,8 @@ * access time can be modified. */ #define WRITEALLOWED(vp) \ - ((vp)->v_vfsp && ((vp)->v_vfsp->vfs_flag & VFS_RDONLY) == 0) - + (((vp)->v_vfsp && ((vp)->v_vfsp->vfs_flag & VFS_RDONLY) == 0) || \ + ((vp)->v_type != VREG ) && ((vp)->v_type != VDIR) && ((vp)->v_type != VLNK)) /* * Global vnode allocation: * From owner-linux-xfs@oss.sgi.com Thu Jan 18 22:37:56 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 22:37:37 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:64262 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 22:37:16 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id EAA01403; Fri, 19 Jan 2001 04:37:05 -0200 Date: Fri, 19 Jan 2001 02:47:07 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: linux-xfs@oss.sgi.com Subject: pagebuf page cleaner and page aging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I've noticed that the page cleaner daemon, which is supposed to map delayed allocations to disk when necessary (out of memory), walks sequentially through whole memory searching for "delayed allocated" pages. I think there is a problem here -- the page cleaner should take page aging information into account. While the VM maybe trying to sync relatively old pages which are in the inactive_dirty list, the page cleaner is mapping relatively new "delayed allocated" pages to disk. The right thing, IMHO, is to make the page cleaner look at the inactive dirty list when we are under a low memory condition. This way it will map "older" dirty pages, making it possible for page_launder() to sync them to disk and potentially free them later. Comments? From owner-linux-xfs@oss.sgi.com Thu Jan 18 22:58:56 2001 Received: by oss.sgi.com id ; Thu, 18 Jan 2001 22:58:36 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:8288 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 Jan 2001 22:58:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA25947 for ; Thu, 18 Jan 2001 22:57:13 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA98407 for linux-xfs@oss.sgi.com; Fri, 19 Jan 2001 17:56:49 +1100 (EST) Date: Fri, 19 Jan 2001 17:56:49 +1100 (EST) From: Timothy Shimmin Message-Id: <200101190656.RAA98407@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACLS config'ed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Make ACLs compile configurable. Thanks, Nathan, for fixing the config files. --Tim Modid: 2.4.x-xfs:slinx:82559a Date: Thu Jan 18 22:50:04 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs-acl Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs SOURCES/kernel-2.4.0-i386-BOOT.config - 1.22 SOURCES/kernel-2.4.0-i386-smp.config - 1.24 SOURCES/kernel-2.4.0-i386.config - 1.24 SOURCES/kernel-2.4.0-i586-smp.config - 1.24 SOURCES/kernel-2.4.0-i586.config - 1.25 SOURCES/kernel-2.4.0-i686-enterprise.config - 1.13 SOURCES/kernel-2.4.0-i686-smp.config - 1.27 SOURCES/kernel-2.4.0-i686.config - 1.25 SOURCES/kernel-2.4.0-ia64-smp.config - 1.10 SOURCES/kernel-2.4.0-ia64.config - 1.10 linux/Documentation/Configure.help - 1.71 linux/fs/Config.in - 1.52 linux/fs/stat.c - 1.17 linux/fs/xfs/Makefile - 1.115 linux/fs/xfs/linux/xfs_globals.c - 1.22 linux/fs/xfs/linux/xfs_iops.c - 1.89 linux/fs/xfs/linux/xfs_vnode.h - 1.14 linux/fs/xfs/xfs.h - 1.15 linux/fs/xfs/xfs_acl.c - 1.2 linux/fs/xfs/xfs_acl.h - 1.2 linux/fs/xfs/xfs_inode.c - 1.310 linux/fs/xfs/xfs_vfsops.c - 1.306 linux/fs/xfs/xfs_vnodeops.c - 1.486 From owner-linux-xfs@oss.sgi.com Fri Jan 19 04:50:29 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 04:50:20 -0800 Received: from hermes.mixx.net ([212.84.196.2]:45322 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Fri, 19 Jan 2001 04:49:56 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id 1BFCBF803 for ; Fri, 19 Jan 2001 13:49:54 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id AEE582CA6F; Fri, 19 Jan 2001 13:49:53 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: missing dirs in the cvs tree Date: 19 Jan 2001 12:49:53 GMT Organization: innominate AG, Berlin, Germany Lines: 21 Distribution: local Message-ID: Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 979908593 22391 10.0.0.31 (19 Jan 2001 12:49:53 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing maybe i am missing something here - but it looks like the external XFS cvs tree is missing some directories: linux/Documentation linux/drivers/[arcorn,block,cdrom,ieee1394,input,macintosh,media, nubus,parport,pcmcia,scsi/aic7xxx,scsi/pcmcia,sound, telephony,video,zorro] can anyone please have a look at this? (also on http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/ the Documentation directory is for instance missing) t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Fri Jan 19 06:51:52 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 06:51:32 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:23604 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 06:51:07 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA04790 for ; Fri, 19 Jan 2001 06:51:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA517407; Fri, 19 Jan 2001 08:49:44 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA98287; Fri, 19 Jan 2001 08:49:44 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JEonK02171; Fri, 19 Jan 2001 08:50:49 -0600 Message-Id: <200101191450.f0JEonK02171@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thomas Graichen , thomas.graichen@innominate.com cc: linux-xfs@oss.sgi.com Subject: Re: missing dirs in the cvs tree In-Reply-To: Message from Thomas Graichen of "19 Jan 2001 12:49:53 GMT." Date: Fri, 19 Jan 2001 08:50:49 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > maybe i am missing something here - but it looks like the external > XFS cvs tree is missing some directories: No I do not think you are, I noticed this last night too. There were some changes yesterday in which directories we do not export to cvs, maybe there was a mistake made - or something broke. Russell is the guy who knows how this works, he tends to work the late shift, so it will probably be a few hours before it gets fixed. Steve > > linux/Documentation > linux/drivers/[arcorn,block,cdrom,ieee1394,input,macintosh,media, > nubus,parport,pcmcia,scsi/aic7xxx,scsi/pcmcia,sound, > telephony,video,zorro] > > can anyone please have a look at this? (also on > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/ Yes, lots of stuff missing from drivers here too - probably the same script. > > the Documentation directory is for instance missing) > > t > > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Fri Jan 19 07:11:22 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 07:11:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3903 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 07:10: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 HAA16510 for ; Fri, 19 Jan 2001 07:09:34 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA518203; Fri, 19 Jan 2001 09:09:12 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA21486; Fri, 19 Jan 2001 09:09:12 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JFAHs02250; Fri, 19 Jan 2001 09:10:17 -0600 Message-Id: <200101191510.f0JFAHs02250@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti cc: Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: Message from Marcelo Tosatti of "Fri, 19 Jan 2001 02:47:07 -0200." Date: Fri, 19 Jan 2001 09:10:17 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Hi, > > I've noticed that the page cleaner daemon, which is supposed to map > delayed allocations to disk when necessary (out of memory), walks > sequentially through whole memory searching for "delayed allocated" pages. > > I think there is a problem here -- the page cleaner should take page aging > information into account. > > While the VM maybe trying to sync relatively old pages which are in the > inactive_dirty list, the page cleaner is mapping relatively new "delayed > allocated" pages to disk. > > The right thing, IMHO, is to make the page cleaner look at the inactive > dirty list when we are under a low memory condition. > > This way it will map "older" dirty pages, making it possible for > page_launder() to sync them to disk and potentially free them later. > > Comments? Yes you are correct in that the page cleaner is insensitive to the age of the data it is working on, it is in effect random. There are a couple of points to be made on the daemon. First, we would really like not to have the daemon in its current state at all and use an address space flush operation to trigger the activity and drive this out of the vm system directly - from discussions in Miami at the storage workshop, the correct way to do this may still involve a special daemon for xfs, but it would be handed work by the vm. This would also be used for subsequent writes of data (non delayed allocation) which currently use buffer heads, I/O clustering could then be applied to those writes as well. Getting to this stage would involve abstracting knowledge of buffer heads out of the vm and hiding them behind another flush method (I think). The flush call would have to be free to flush more or different data than it was requested to. Second, your initial comment misses one of the points of the page cleaner, that it is the only thread of activity which is going to move delalloc pages out to disk, if it was based purely on aging out pages due to pressure then you could end up with data written to files not getting flushed to disk for a very long time. Delayed allocate data needs to be treated more like other writes to disk. Pagebuf has a long way to go before it is a completed project, especially if kiobufs get the revamp which appears to be on its way! Steve From owner-linux-xfs@oss.sgi.com Fri Jan 19 07:12:21 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 07:12:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:12353 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 07:11:53 -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 HAA17210 for ; Fri, 19 Jan 2001 07:10:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA512914; Fri, 19 Jan 2001 09:10:33 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA90127; Fri, 19 Jan 2001 09:10:33 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JFBcP02257; Fri, 19 Jan 2001 09:11:38 -0600 Message-Id: <200101191511.f0JFBcP02257@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Timothy Shimmin cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - ACLS config'ed In-Reply-To: Message from Timothy Shimmin of "Fri, 19 Jan 2001 17:56:49 +1100." <200101190656.RAA98407@snort.melbourne.sgi.com> Date: Fri, 19 Jan 2001 09:11:38 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Make ACLs compile configurable. > Thanks, Nathan, for fixing the config files. Are you sure we should do it this way? The previous mechanism which you removed involved no inline ifdefs, you just linked in the stub file or the actual implementation of acls, all the mainline code was capable of working either way. Steve > > --Tim > > Modid: 2.4.x-xfs:slinx:82559a > Date: Thu Jan 18 22:50:04 PST 2001 > Workarea: snort:/diskb/build4/tes/slinx-xfs-acl > Author: tes > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > SOURCES/kernel-2.4.0-i386-BOOT.config - 1.22 > SOURCES/kernel-2.4.0-i386-smp.config - 1.24 > SOURCES/kernel-2.4.0-i386.config - 1.24 > SOURCES/kernel-2.4.0-i586-smp.config - 1.24 > SOURCES/kernel-2.4.0-i586.config - 1.25 > SOURCES/kernel-2.4.0-i686-enterprise.config - 1.13 > SOURCES/kernel-2.4.0-i686-smp.config - 1.27 > SOURCES/kernel-2.4.0-i686.config - 1.25 > SOURCES/kernel-2.4.0-ia64-smp.config - 1.10 > SOURCES/kernel-2.4.0-ia64.config - 1.10 > linux/Documentation/Configure.help - 1.71 > linux/fs/Config.in - 1.52 > linux/fs/stat.c - 1.17 > linux/fs/xfs/Makefile - 1.115 > linux/fs/xfs/linux/xfs_globals.c - 1.22 > linux/fs/xfs/linux/xfs_iops.c - 1.89 > linux/fs/xfs/linux/xfs_vnode.h - 1.14 > linux/fs/xfs/xfs.h - 1.15 > linux/fs/xfs/xfs_acl.c - 1.2 > linux/fs/xfs/xfs_acl.h - 1.2 > linux/fs/xfs/xfs_inode.c - 1.310 > linux/fs/xfs/xfs_vfsops.c - 1.306 > linux/fs/xfs/xfs_vnodeops.c - 1.486 From owner-linux-xfs@oss.sgi.com Fri Jan 19 08:16:12 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 08:15:52 -0800 Received: from ns.caldera.de ([212.34.180.1]:46096 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 08:15:44 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id RAA14591; Fri, 19 Jan 2001 17:15:17 +0100 Date: Fri, 19 Jan 2001 17:15:17 +0100 From: Christoph Hellwig To: Steve Lord Cc: Marcelo Tosatti , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging Message-ID: <20010119171517.B11711@caldera.de> References: <200101191510.f0JFAHs02250@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200101191510.f0JFAHs02250@jen.americas.sgi.com>; from lord@sgi.com on Fri, Jan 19, 2001 at 09:10:17AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Jan 19, 2001 at 09:10:17AM -0600, Steve Lord wrote: > First, we would really like not to have the daemon in its current state > at all and use an address space flush operation to trigger the activity > and drive this out of the vm system directly - from discussions in Miami > at the storage workshop, the correct way to do this may still involve a > special daemon for xfs, but it would be handed work by the vm. This would > also be used for subsequent writes of data (non delayed allocation) which > currently use buffer heads, I/O clustering could then be applied to those > writes as well. Getting to this stage would involve abstracting knowledge > of buffer heads out of the vm and hiding them behind another flush method > (I think). The flush call would have to be free to flush more or different > data than it was requested to. I personally think that we _really_ want to get rid of buffer_heads in mm in Linux 2.5. But I think settings the page dirty in prepare/commit_write and letting writepage do all the dirty work is cleaner and lets us get rid of most of the buffer cache logic even before buffer_heads are completly gone (if they will ever be gone ....). > > Pagebuf has a long way to go before it is a completed project, especially > if kiobufs get the revamp which appears to be on its way! > Yes. Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Fri Jan 19 08:30:12 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 08:29:53 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:35079 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 08:29:23 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id OAA04791; Fri, 19 Jan 2001 14:28:23 -0200 Date: Fri, 19 Jan 2001 12:38:27 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: <200101191510.f0JFAHs02250@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 19 Jan 2001, Steve Lord wrote: > Yes you are correct in that the page cleaner is insensitive to the age > of the data it is working on, it is in effect random. > > There are a couple of points to be made on the daemon. > > First, we would really like not to have the daemon in its current state > at all and use an address space flush operation to trigger the activity > and drive this out of the vm system directly - from discussions in Miami > at the storage workshop, the correct way to do this may still involve a > special daemon for xfs, but it would be handed work by the vm. This would > also be used for subsequent writes of data (non delayed allocation) which > currently use buffer heads, I/O clustering could then be applied to those > writes as well. > Getting to this stage would involve abstracting knowledge of buffer > heads out of the vm and hiding them behind another flush method (I > think). Thats ->writepage(), basically. The problem with write clustering right now is that there is no abstraction defined. > The flush call would have to be free to flush more or different data > than it was requested to. The VM must "control" what is flushed, IMO: - the address space owner does not have access to the aging information VM code has. For example, we probably want to only cluster pages which are on the inactive dirty list, and this information belongs to VM. - In low memory conditions, the VM knows the right balancing between swapping and syncing of pages. - If the write clustering gets done at VM level, we potentially avoid code reuse. Obviously the VM does not have knowledge about the filesystem low-level information, which is also needed to get write clustering right. To solve that, we can add a new operation to the address-space structure which can allow the address space owner to inform the VM if clustering is worth in a given range of disk. Something like this: int (*cluster)(struct page *page, unsigned long *boffset, unsigned long *foffset); page = page currently being written by VM b/foffset = Pointers passed to the address space owner so it can inform backward/forward offset starting from the logical offset in the inode (page->index) describing upto where the write clustering is worth to be done. I hope to have something similar working soon. Comments? > Second, your initial comment misses one of the points of the page cleaner, > that it is the only thread of activity which is going to move delalloc pages > out to disk, if it was based purely on aging out pages due to pressure then > you could end up with data written to files not getting flushed to disk > for a very long time. Delayed allocate data needs to be treated more like > other writes to disk. Indeed. From owner-linux-xfs@oss.sgi.com Fri Jan 19 09:09:41 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 09:09:22 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:37750 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 09:09:02 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA01626 for ; Fri, 19 Jan 2001 09:09:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA516452; Fri, 19 Jan 2001 11:07:44 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA61288; Fri, 19 Jan 2001 11:07:43 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JH8lN27127; Fri, 19 Jan 2001 11:08:47 -0600 Message-Id: <200101191708.f0JH8lN27127@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti cc: Steve Lord , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: Message from Marcelo Tosatti of "Fri, 19 Jan 2001 12:38:27 -0200." Date: Fri, 19 Jan 2001 11:08:47 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > On Fri, 19 Jan 2001, Steve Lord wrote: > > > > Getting to this stage would involve abstracting knowledge of buffer > > heads out of the vm and hiding them behind another flush method (I > > think). > > Thats ->writepage(), basically. The problem with write clustering right > now is that there is no abstraction defined. > > > The flush call would have to be free to flush more or different data > > than it was requested to. > > The VM must "control" what is flushed, IMO: > > - the address space owner does not have access to the aging information VM > code has. For example, we probably want to only cluster pages which are on > the inactive dirty list, and this information belongs to VM. > - In low memory conditions, the VM knows the right balancing between > swapping and syncing of pages. > - If the write clustering gets done at VM level, we potentially avoid code > reuse. There are other aspects of write clustering which are important - at least as far as xfs is concerned. When xfs is asked to flush a delayed allocate page it goes and allocates space for it and all other delalloc space contiguous with it in the file. Even if some of this space is not aged enough for the vm to consider it a candidate for flushing, if we are going to be doing a disk I/O for pages which are on disk contiguous with it, we can as part of the same disk operation clean this one too. Deciding to break this disk I/O into multiple ones based on age is a trade off between the page getting remodified later on (requiring another write) and having to do more disk I/O later to clean the page. I would contend that writing the extra pages (within some reasonable bound to avoid saturating the devices with a huge request) is going to end up with less disk I/O than we would otherwise have. > > Obviously the VM does not have knowledge about the filesystem low-level > information, which is also needed to get write clustering right. > > To solve that, we can add a new operation to the address-space structure > which can allow the address space owner to inform the VM if clustering is > worth in a given range of disk. Something like this: > > int (*cluster)(struct page *page, unsigned long *boffset, > unsigned long *foffset); > > page = page currently being written by VM > > b/foffset = Pointers passed to the address space owner so it can inform > backward/forward offset starting from the logical offset in the inode > (page->index) describing upto where the write clustering is worth to > be done. > > I hope to have something similar working soon. > > Comments? Having cluster and a bmap operation as distinct operations means two calls into the filesystem to work out where pages live on disk, if we are going to cluster the actual I/O and have the vm system do the clustering work then this may be better combined into a single call. There is one other snag which this will cause XFS, there is a feature we have not implemented yet on Linux which will require xfs to obtain control again after the I/O for a write has completed in some cases. XFS supports space preallocation, where an extent is created in advance for data - when an application knows it will require a set amount of space, this gives the allocator a better chance for doing good on disk layout. Now since this space has not been written to, we need to prevent it from being read, since it could contain any data. Therefore the extent is marked as unwritten when we preallocate, unwritten extents always read as zeros. We need to change this state after the write completes. From the point of view of XFS, letting it initiate the actual write would let it do this. All this may mean is redirecting the actual I/O request through a vector which would have a default implementation. Steve > > > Second, your initial comment misses one of the points of the page cleaner, > > that it is the only thread of activity which is going to move delalloc page > s > > out to disk, if it was based purely on aging out pages due to pressure then > > you could end up with data written to files not getting flushed to disk > > for a very long time. Delayed allocate data needs to be treated more like > > other writes to disk. > > Indeed. > > > > From owner-linux-xfs@oss.sgi.com Fri Jan 19 09:17:31 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 09:17:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:51771 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 09:17:05 -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 JAA02495 for ; Fri, 19 Jan 2001 09:16:07 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA518803 for ; Fri, 19 Jan 2001 11:15:48 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA57390 for ; Fri, 19 Jan 2001 11:15:48 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0JHGql27297; Fri, 19 Jan 2001 11:16:52 -0600 Message-Id: <200101191716.f0JHGql27297@jen.americas.sgi.com> Date: Fri, 19 Jan 2001 11:16:52 -0600 Subject: TAKE - fix extended attribute tests To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The name of the command changed Date: Fri Jan 19 09:15:32 PST 2001 Workarea: 128.162.184.86:/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:82571a cmd/xfstests/021 - 1.2 cmd/xfstests/020 - 1.2 - xfs_attr is now called attr From owner-linux-xfs@oss.sgi.com Fri Jan 19 09:39:01 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 09:38:42 -0800 Received: from ns.caldera.de ([212.34.180.1]:22289 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 09:38:27 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id SAA24839; Fri, 19 Jan 2001 18:38:03 +0100 Date: Fri, 19 Jan 2001 18:38:03 +0100 From: Christoph Hellwig To: Marcelo Tosatti Cc: Steve Lord , Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging Message-ID: <20010119183803.A23862@caldera.de> References: <200101191510.f0JFAHs02250@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from marcelo@conectiva.com.br on Fri, Jan 19, 2001 at 12:38:27PM -0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Jan 19, 2001 at 12:38:27PM -0200, Marcelo Tosatti wrote: > Obviously the VM does not have knowledge about the filesystem low-level > information, which is also needed to get write clustering right. IMHO we should try to give the VM knowlede how to cluster without having to go into the low-level code at all. The idea I had for such information is the notation of a virtual extent. A virtual extend would simply be a list-head in the struct page that links a pages together that are worth clustering because they are either real extents (because the fs supports it) or just continguos aligned on disk for block-based filesystems (yeah, we have to do magic on readtime to get this information, best by a readpage op). The disadvantage of this appropeach is that it bloats struct page even more... Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Fri Jan 19 10:07:01 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 10:06:42 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:49927 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 10:06:36 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id QAA05453; Fri, 19 Jan 2001 16:06:27 -0200 Date: Fri, 19 Jan 2001 14:16:31 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: Rajagopal Ananthanarayanan , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: <200101191708.f0JH8lN27127@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 19 Jan 2001, Steve Lord wrote: > There are other aspects of write clustering which are important - at least > as far as xfs is concerned. I would like to have write clustering scheme which can work with advanced features (such as delayed allocation) even if we dont have those features right now in the kernel. Otherwise we'll end up having different implementations (hum, kludges) for the same thing which are hard to maintain. > When xfs is asked to flush a delayed allocate > page it goes and allocates space for it and all other delalloc space > contiguous with it in the file. Even if some of this space is not > aged enough for the vm to consider it a candidate for flushing, if we > are going to be doing a disk I/O for pages which are on disk contiguous > with it, we can as part of the same disk operation clean this one too. > > Deciding to break this disk I/O into multiple ones based on age is a > trade off between the page getting remodified later on (requiring another > write) and having to do more disk I/O later to clean the page. I would > contend that writing the extra pages (within some reasonable bound to > avoid saturating the devices with a huge request) is going to end up > with less disk I/O than we would otherwise have. With the ->cluster() operation, XFS can allocate these contiguous pages and tell the VM subsystem about them (with the "boffset" and "poffset" pointers). What you think? > > > > Obviously the VM does not have knowledge about the filesystem low-level > > information, which is also needed to get write clustering right. > > > > To solve that, we can add a new operation to the address-space structure > > which can allow the address space owner to inform the VM if clustering is > > worth in a given range of disk. Something like this: > > > > int (*cluster)(struct page *page, unsigned long *boffset, > > unsigned long *foffset); > > > > page = page currently being written by VM > > > > b/foffset = Pointers passed to the address space owner so it can inform > > backward/forward offset starting from the logical offset in the inode > > (page->index) describing upto where the write clustering is worth to > > be done. > > > > I hope to have something similar working soon. > > > > Comments? > > Having cluster and a bmap operation as distinct operations means two calls > into the filesystem to work out where pages live on disk, if we are going > to cluster the actual I/O and have the vm system do the clustering work > then this may be better combined into a single call. They are different (for example the delayed allocation issue). > > There is one other snag which this will cause XFS, there is a feature we > have not implemented yet on Linux which will require xfs to obtain control > again after the I/O for a write has completed in some cases. XFS supports > space preallocation, where an extent is created in advance for data - when > an application knows it will require a set amount of space, this gives the > allocator a better chance for doing good on disk layout. Now since this > space has not been written to, we need to prevent it from being read, > since it could contain any data. Therefore the extent is marked as unwritten > when we preallocate, unwritten extents always read as zeros. We need to > change this state after the write completes. From the point of view of XFS, > letting it initiate the actual write would let it do this. All this may > mean is redirecting the actual I/O request through a vector which would > have a default implementation. Do you think its ok for XFS to handle this special case on its own ->writepage()? Do you have more special cases? :) From owner-linux-xfs@oss.sgi.com Fri Jan 19 10:25:21 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 10:25:01 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:56348 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 10:24:48 -0800 Received: from madurai.engr.sgi.com ([163.154.5.75]) 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 KAA03842 for ; Fri, 19 Jan 2001 10:24:35 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA57736; Fri, 19 Jan 2001 10:18:16 -0800 (PST) Message-ID: <3A688567.9CC4CE7A@sgi.com> Date: Fri, 19 Jan 2001 10:20:23 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging References: <200101191510.f0JFAHs02250@jen.americas.sgi.com> <20010119183803.A23862@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing There's been several mail exchanges already on this thread. Let me try to summarize: 1. The page cleaner should walk the dirty list of pages. 2. There are 2 reasons to start write-out earlier than on just memory pressure/aging information alone. (a) to minimize data lost due to delalloc pages not written to disk (b) to minimize write pressure on the disk .. you don't want to fill-up a 1GB system with delalloc pages & starting to write out at 20 MB/sec to disk. 3. Its almost tempting to make kswapd do the delalloc conversions, since it walks the inactive dirty list through page_launder(). However, if you think about it, the conversion is an operation that logically sits between make a page delalloc & writing it out to disk. IMO, we need a seperate daemon to perform the conversions. 4. Another issue is proper write-throttling to avoid situations as in 2 (b). Perhaps we can make balance_dirty() to synchronously perform some conversions? -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jan 19 10:45:22 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 10:45:01 -0800 Received: from ns.caldera.de ([212.34.180.1]:55313 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 10:44:52 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id TAA31893; Fri, 19 Jan 2001 19:44:33 +0100 Date: Fri, 19 Jan 2001 19:44:33 +0100 From: Christoph Hellwig To: Rajagopal Ananthanarayanan Cc: Christoph Hellwig , Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging Message-ID: <20010119194433.A29540@caldera.de> References: <200101191510.f0JFAHs02250@jen.americas.sgi.com> <20010119183803.A23862@caldera.de> <3A688567.9CC4CE7A@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A688567.9CC4CE7A@sgi.com>; from ananth@sgi.com on Fri, Jan 19, 2001 at 10:20:23AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, Jan 19, 2001 at 10:20:23AM -0800, Rajagopal Ananthanarayanan wrote: > > There's been several mail exchanges already on this thread. > Let me try to summarize: > > 1. The page cleaner should walk the dirty list of pages. Yepp. > 2. There are 2 reasons to start write-out earlier than on > just memory pressure/aging information alone. (a) to minimize > data lost due to delalloc pages not written to disk (b) to minimize > write pressure on the disk .. you don't want to fill-up a 1GB system > with delalloc pages & starting to write out at 20 MB/sec to disk. (b) should be handled in a generic way (by the mm subsys), but I'm not sure how to do (a). > 3. Its almost tempting to make kswapd do the delalloc conversions, > since it walks the inactive dirty list through page_launder(). > However, if you think about it, the conversion is an operation > that logically sits between make a page delalloc & writing it out to > disk. IMO, we need a seperate daemon to perform the conversions. Agreed. Again it should be handled outside XFS, e.g. my generic kiobuf address_space methods start using delayed allocation (in a hairy way ...). Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Fri Jan 19 13:14:52 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 13:14:42 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:7944 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 13:14:36 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id TAA06549; Fri, 19 Jan 2001 19:14:20 -0200 Date: Fri, 19 Jan 2001 17:24:25 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: <3A688567.9CC4CE7A@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 19 Jan 2001, Rajagopal Ananthanarayanan wrote: > > There's been several mail exchanges already on this thread. > Let me try to summarize: > 3. Its almost tempting to make kswapd do the delalloc conversions, > since it walks the inactive dirty list through page_launder(). > However, if you think about it, the conversion is an operation > that logically sits between make a page delalloc & writing it out to > disk. IMO, we need a seperate daemon to perform the conversions. Ananth, Its obvious there must be a daemon to allocate old unmapped pages and to help write throttling of the delayed allocations. Now I dont see any problem with write clustering (potentially converting pages if we found delayed pages). Remember that page_launder() is called by each process since 2.4.1pre2, so there is no big problem if kswapd blocks trying to convert pages. What I'm missing here? From owner-linux-xfs@oss.sgi.com Fri Jan 19 13:17:12 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 13:16:52 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:46694 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 13:16:44 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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 NAA05510 for ; Fri, 19 Jan 2001 13:16:43 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA13385 for ; Fri, 19 Jan 2001 15:15:27 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f0JLER404808 for linux-xfs@oss.sgi.com; Fri, 19 Jan 2001 15:14:27 -0600 Date: Fri, 19 Jan 2001 15:14:27 -0600 From: Russell Cattelan Message-Id: <200101192114.f0JLER404808@gibble.americas.sgi.com> Subject: TAKE - merge /dev RO fix to beta2 To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Fri Jan 19 13:14:09 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta2 Author: lord Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:82527a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta2 Modid: 2.4.x-xfs-beta2:slinx:82527a linux/fs/xfs/linux/xfs_vnode.h - 1.10 - Merge of 2.4.x-xfs:slinx:82527a by cattelan. Chare readonly filesystem check so it does not apply to devices From owner-linux-xfs@oss.sgi.com Fri Jan 19 13:21:12 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 13:20:52 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:26984 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 13:20:44 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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 NAA07349 for ; Fri, 19 Jan 2001 13:20:42 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA15433; Fri, 19 Jan 2001 15:19:26 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0JLIQd04818; Fri, 19 Jan 2001 15:18:26 -0600 Message-ID: <3A68AF21.837A57B6@thebarn.com> Date: Fri, 19 Jan 2001 15:18:25 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graichen CC: linux-xfs@oss.sgi.com Subject: Re: missing dirs in the cvs tree References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Thomas Graichen wrote: Ok I think everything is up to date. I think one of the links in the chain ran out of disk space. I clean the whole mess out and let the process start from scratch. Note: The Beta tree has been bumped up... it is now based on the tree that will be used for the pending prerelease. > > maybe i am missing something here - but it looks like the external > XFS cvs tree is missing some directories: > > linux/Documentation > linux/drivers/[arcorn,block,cdrom,ieee1394,input,macintosh,media, > nubus,parport,pcmcia,scsi/aic7xxx,scsi/pcmcia,sound, > telephony,video,zorro] > > can anyone please have a look at this? (also on > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/ > > the Documentation directory is for instance missing) > > t > > -- > thomas.graichen@innominate.com > innominate AG > the linux architects > tel: +49-30-308806-13 fax: -77 http://www.innominate.com -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Fri Jan 19 13:30:43 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 13:30:33 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:33900 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 13:30:08 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05678 for ; Fri, 19 Jan 2001 13:30:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA524582 for ; Fri, 19 Jan 2001 15:28:48 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA70476 for ; Fri, 19 Jan 2001 15:28:48 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0JLTls30653; Fri, 19 Jan 2001 15:29:47 -0600 Message-Id: <200101192129.f0JLTls30653@jen.americas.sgi.com> Date: Fri, 19 Jan 2001 15:29:47 -0600 Subject: TAKE - clean up some unused locking code To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The previous change to add VOP_STRATEGY meant some old locking code was no longer needed, this removes the associated logic. Date: Fri Jan 19 13:27:41 PST 2001 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:82600a linux/fs/xfs/linux/xfs_lrw.c - 1.72 - remove PBF_BMAP_TRY_ILOCK from xfs_bmap linux/fs/xfs/linux/xfs_fs_subr.c - 1.26 - comment out printk linux/fs/xfs/linux/xfs_iops.c - 1.90 - rework linvfs_pb_bmap so it does its own inode locking rather than passing PBF_BMAP_TRY_ILOCK down into VOP_BMAP. linux/include/linux/page_buf.h - 1.69 - remove PBF_BMAP_TRY_ILOCK linux/fs/pagebuf/page_buf_io.c - 1.42 - Remove PBF_BMAP_TRY_ILOCK and associated handling, this path is no longer used. From owner-linux-xfs@oss.sgi.com Fri Jan 19 13:45:13 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 13:44:54 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57201 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 13:44:39 -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 LAA01711 for ; Thu, 18 Jan 2001 11:29:30 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA509521; Thu, 18 Jan 2001 13:19:18 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA42620; Thu, 18 Jan 2001 13:19:18 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0IJK8t23420; Thu, 18 Jan 2001 13:20:08 -0600 Message-Id: <200101181920.f0IJK8t23420@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: utz lehmann , "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from Steve Lord of "Thu, 18 Jan 2001 13:00:11 CST." <200101181900.f0IJ0Bi23236@jen.americas.sgi.com> Date: Thu, 18 Jan 2001 13:20:08 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > hi > > > > > > i have the same problem: > > > > OK I am going back to try and reproduce this here, I think I know how > > to I was building the kernel when I hit it. > > > Yep, this was very simple to hit, running with /dev inside of XFS appears > to be part of it - I am running on an ide root, not sure how that factors > in to it. I suspect a problem in dev handling inside XFS, so a workaround > would be to run devfs with the mount at boot time option (ok I know that is > not always an option) or a non-xfs /dev directory in some other way. If you > have redhat 7 devfs is not actually painful to get going. > > Steve > OK, I have to go off the air for a while here, but I think the problem is due to opening the console read/write before the filesystem is read/write, a very basic work around would be to comment out this check: if ((mode & IWRITE) && !WRITEALLOWED(XFS_ITOV(ip))) return XFS_ERROR(EROFS); at line 3486 of fs/xfs/xfs_inode.c This is a guess and is not the correct final solution. It all has to do with xfs doing its own permission checks I think. Can someone try and let me know. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 19 14:18:03 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 14:17:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8318 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 14:17:30 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01205 for ; Thu, 18 Jan 2001 10:46:26 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA56214; Thu, 18 Jan 2001 10:32:02 -0800 (PST) Message-ID: <3A673723.B6E774D2@sgi.com> Date: Thu, 18 Jan 2001 10:34:11 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Marcelo E. Magallon" CC: linux-xfs@oss.sgi.com Subject: Re: Can't get initial console References: <200101181605.f0IG5vk22584@jen.americas.sgi.com> <20010118183555.A5796@techno.informatik.uni-stuttgart.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Marcelo E. Magallon" wrote: > > >> Steve Lord writes: > > > This may be your problem - I think IDE had some bad days, have you > > tried stuff beyond this date, or are you in the process of narrowing > > down when it broke? > > Yes, just finished trying all the builds I have between the 10th and > today, and no, none of them will boot, and I haven't seen anything like > this on lkml, so I thought this was somehow specific to the XFS tree. > Are you running XFS root? I just installed the lastest CD and ran into the same problem when I tried to run a kernel I compiled. One change that fixes this problem (as Steve pointed out, i think) is to turn on DEVFS. At this time, I have no idea why this is required. ananth. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jan 19 14:24:03 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 14:23:43 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:12843 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 14:23:37 -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 OAA18988 for ; Fri, 19 Jan 2001 14:22:39 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA524874; Fri, 19 Jan 2001 16:22:13 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA99304; Fri, 19 Jan 2001 16:22:13 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JMNC332462; Fri, 19 Jan 2001 16:23:12 -0600 Message-Id: <200101192223.f0JMNC332462@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Rajagopal Ananthanarayanan cc: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from Rajagopal Ananthanarayanan of "Thu, 18 Jan 2001 10:34:11 PST." <3A673723.B6E774D2@sgi.com> Date: Fri, 19 Jan 2001 16:23:12 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Looks like email is playing up again - this should all be fixed in the cvs tree now. I keep getting bounce messages about hosts not being reachable - it does not like this topic for some reason! Steve > "Marcelo E. Magallon" wrote: > > > > >> Steve Lord writes: > > > > > This may be your problem - I think IDE had some bad days, have you > > > tried stuff beyond this date, or are you in the process of narrowing > > > down when it broke? > > > > Yes, just finished trying all the builds I have between the 10th and > > today, and no, none of them will boot, and I haven't seen anything like > > this on lkml, so I thought this was somehow specific to the XFS tree. > > > > Are you running XFS root? I just installed the lastest CD > and ran into the same problem when I tried to run a kernel > I compiled. One change that fixes this problem (as Steve > pointed out, i think) is to turn on DEVFS. At this time, I > have no idea why this is required. > > ananth. > > -------------------------------------------------------------------------- > Rajagopal Ananthanarayanan ("ananth") > Member Technical Staff, SGI. > -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jan 19 14:27:03 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 14:26:43 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43524 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 14:26:28 -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 HAA04798 for ; Fri, 19 Jan 2001 07:28:49 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA519038; Fri, 19 Jan 2001 09:18:38 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA40391; Fri, 19 Jan 2001 09:18:38 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0JFJhK04217; Fri, 19 Jan 2001 09:19:43 -0600 Message-Id: <200101191519.f0JFJhK04217@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Marcelo E. Magallon" , linux-xfs@oss.sgi.com Subject: Re: Can't get initial console In-Reply-To: Message from "Marcelo E. Magallon" of "Fri, 19 Jan 2001 02:55:01 +0100." <20010119025501.B11358@rock.informatik.uni-stuttgart.de> Date: Fri, 19 Jan 2001 09:19:43 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing For some reason my email on the fix for this never went out (maybe the fact that the lights are going on and off in California has something to do with it), there is now a fix for this problem in the cvs tree. Steve > >> Steve Lord writes: > > > Yep, this was very simple to hit, running with /dev inside of XFS > > appears to be part of it - I am running on an ide root, not sure how > > that factors in to it. I suspect a problem in dev handling inside > > XFS > > Might be. devfs "fixes" this because it's not mounted ro but rw. > > Now I have a general idea where the problem might be, I'll take a look > tomorrow, I need to sleep now. > > Thanks, > > -- > Marcelo From owner-linux-xfs@oss.sgi.com Fri Jan 19 15:33:33 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 15:33:23 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:2114 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 15:33:04 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA29734 for ; Fri, 19 Jan 2001 15:32:07 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA57961; Fri, 19 Jan 2001 15:26:39 -0800 (PST) Message-ID: <3A68CDAD.C2B35A3B@sgi.com> Date: Fri, 19 Jan 2001 15:28:45 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > > Now I dont see any problem with write clustering (potentially converting > pages if we found delayed pages). Remember that page_launder() is called > by each process since 2.4.1pre2, so there is no big problem if kswapd > blocks trying to convert pages. You are referring to writepage() doing the conversion & clustering when called from page_launder()? IOW, do the conversion/clustering as part of the memory allocation, right? There are no major issues with it: infact at one point I had the convertpage() call out of page_launder to do conversions inplace, instead of waking up the page_cleaner daemon. Two potential pitfalls. (1) the conversion/clustering can involve memory allocation --- now you are allocating more memory when already trying to allocate memory (and in fact facing a shortage of memory) ... can the process now be marked PF_MEMALLOC? (2) potential locking problems in the FS. If the original memory allocation is done under a lock, as is the case in XFS, which holds the IOLOCK, then the convert call should be able to trylock & bail. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Fri Jan 19 16:01:23 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 16:01:04 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:26376 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 16:00:48 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id WAA07435; Fri, 19 Jan 2001 22:00:36 -0200 Date: Fri, 19 Jan 2001 20:10:42 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Rajagopal Ananthanarayanan cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: pagebuf page cleaner and page aging In-Reply-To: <3A68CDAD.C2B35A3B@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Fri, 19 Jan 2001, Rajagopal Ananthanarayanan wrote: > Marcelo Tosatti wrote: > > > > > > > Now I dont see any problem with write clustering (potentially converting > > pages if we found delayed pages). Remember that page_launder() is called > > by each process since 2.4.1pre2, so there is no big problem if kswapd > > blocks trying to convert pages. > > You are referring to writepage() doing the conversion & clustering when > called from page_launder()? IOW, do the conversion/clustering as part of > the memory allocation, right? Not really . > There are no major issues with it: infact at one point I had the > convertpage() call out of page_launder to do conversions inplace, > instead of waking up the page_cleaner daemon. Two potential pitfalls. > (1) the conversion/clustering can involve memory allocation --- now > you are allocating more memory when already trying to allocate memory > (and in fact facing a shortage of memory) ... can the process now > be marked PF_MEMALLOC? Yes, PF_MEMALLOC can be used. The clustering should be limited (or even removed) if we're under critical memory shortage. These are tuning issues which I'm sure we will have to look more carefully later. > (2) potential locking problems in the FS. If the original memory allocation > is done under a lock, as is the case in XFS, which holds the IOLOCK, > then the convert call should be able to trylock & bail. The cost of fixing this (not so easy) problems is worth IMHO. One of the most interesting parts of this is that we really avoid code replication --- even swap will use the write clustering scheme. From owner-linux-xfs@oss.sgi.com Fri Jan 19 16:46:34 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 16:46:23 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:19514 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 16:46:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07582 for ; Thu, 18 Jan 2001 14:16:59 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA36603 for linux-xfs@oss.sgi.com; Fri, 19 Jan 2001 09:06:45 +1100 (EST) Date: Fri, 19 Jan 2001 09:06:45 +1100 (EST) From: Nathan Scott Message-Id: <200101182206.JAA36603@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82526a Date: Thu Jan 18 14:06:35 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Makefile - 1.37 - bring dmapi rpms into the ProPack build. From owner-linux-xfs@oss.sgi.com Fri Jan 19 16:47:13 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 16:46:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34106 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 16:46:41 -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 OAA08428 for ; Thu, 18 Jan 2001 14:32:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA510764 for ; Thu, 18 Jan 2001 16:21:57 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA45032 for ; Thu, 18 Jan 2001 16:21:56 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0IMN8b01131; Thu, 18 Jan 2001 16:23:08 -0600 Message-Id: <200101182223.f0IMN8b01131@jen.americas.sgi.com> Date: Thu, 18 Jan 2001 16:23:08 -0600 Subject: TAKE - fix console opening problems To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This appears to fix the cannot open initial console message problem Date: Thu Jan 18 14:21:03 PST 2001 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:82527a linux/fs/xfs/linux/xfs_vnode.h - 1.12 - Change readonly filesystem check so it does not apply to devices From owner-linux-xfs@oss.sgi.com Fri Jan 19 16:53:14 2001 Received: by oss.sgi.com id ; Fri, 19 Jan 2001 16:52:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21052 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 Jan 2001 16:52:39 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05213 for ; Thu, 18 Jan 2001 13:39:36 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA44755 for ; Thu, 18 Jan 2001 15:29:27 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0ILSRd13553 for ; Thu, 18 Jan 2001 15:28:27 -0600 Message-ID: <3A675FFA.DB10B92F@thebarn.com> Date: Thu, 18 Jan 2001 15:28:26 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: HEADS UP linux-2.4-beta tree change. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing As part of the pending prerelease of XFS the cvs beta tree on oss will be moved up the the current beta2 tree. If anybody really thinks it should be keep around let me know. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Sun Jan 21 15:16:07 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 15:15:57 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:54355 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 15:15:32 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA01061 for ; Sun, 21 Jan 2001 15:15:29 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA85093 for linux-xfs@oss.sgi.com; Mon, 22 Jan 2001 10:14:06 +1100 (EST) Date: Mon, 22 Jan 2001 10:14:06 +1100 (EST) From: Nathan Scott Message-Id: <200101212314.KAA85093@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing add missing file (thanks Daniel). Modid: 2.4.x-xfs:slinx:82633a Date: Sun Jan 21 15:13:37 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/quota/xbstat.h - 1.1 - defines some xfs types and macros required for the quota tools. From owner-linux-xfs@oss.sgi.com Sun Jan 21 19:01:39 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 19:01:29 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:44804 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 19:01:08 -0800 Received: from thebarn.com ([160.94.232.55]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0M316Q06286 for ; Sun, 21 Jan 2001 21:01:06 -0600 (CST) Message-ID: <3A6BA271.F2031E48@thebarn.com> Date: Sun, 21 Jan 2001 21:01:05 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: cmd/etherboot cmd/mknbi-linux cmd/lockstat ??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing These directories have been tagging along in our tree since the beginning. Can any find a good reason to keep them around? If not I propose we nuke them. -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Jan 21 20:48:29 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 20:48:10 -0800 Received: from [160.94.232.55] ([160.94.232.55]:19466 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 20:47:47 -0800 Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id f0M4li432422 for ; Sun, 21 Jan 2001 22:47:44 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A6BBBA8.A6756F85@thebarn.com> Date: Sun, 21 Jan 2001 22:48:40 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: (Fwd) XFS on Debian References: <10101211036.ZM57374@wobbly.melbourne.sgi.com> <3A6A22CB.C401285C@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Eric Sandeen wrote: Both the current development tree and the beta tree are 2.4.0 based. The prerelease patches can be found at. ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/Jan192001prerelease.patch.gz ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/Jan192001prerelease-cvs.patch.gz The prerelease patches will be updated as bugs are discovered and fixed. The Devel patches as mentioned below are update sporadically, generally whenever the tree is upgraded to the next revision of linux. The quickest way to get up to speed is to download the XFS cvs patch and the linux tree, and patch'er up. Once the the linux-xfs has been CVSatized, updates shouldn't require much network bandwidth. % cvs -z3 update -d should to the trick. > I think that > ftp://oss.sgi.com/projects/xfs/download/Jan182001devel.patch.gz is a > snapshot patch against 2.4.0. > > ftp://oss.sgi.com/projects/xfs/download/Jan182001devel-cvs.patch.gz > contains CVS tags as well. > > > it's not easy to download _uncompressed_ > > (cvs -z3 will use compression for the transfer, BTW) > > -Eric > > Nathan Scott wrote: > > > > hi, > > > > Can someone let me know if we have a 2.4.0 patch on oss at > > this stage? (beta2 looks 2.4.0 based - so I guess we will > > shortly?) > > > > thanks. > > > > --- Forwarded mail from Ben Roberts > > > > Date: Sat, 20 Jan 2001 14:26:39 -0500 > > From: Ben Roberts > > To: nathans@sgi.com > > Subject: XFS on Debian > > > > ...[snip]... > > > > ... and (more importantly) if kernel sources and patches are > > as well, since it's not easy to download _uncompressed_ 2.4 kernel > > source from _cvs_ on a 56k connection. > > > > -- > > > > ---End of forwarded mail from Ben Roberts > > > > -- > > Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 21 20:59:09 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 20:58:59 -0800 Received: from 209-161-7-106.gargoylecc.com ([209.161.7.106]:24704 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 20:58:39 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [209.161.7.106]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id NAA06699 for ; Mon, 22 Jan 2001 13:07:43 -0700 Date: Mon, 22 Jan 2001 13:07:43 -0700 (MST) From: Russel Ingram To: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I know this is a lot later than I promised and I'm not sure if it is still useful, but the first draft of the Linux+XFS-HOWTO doc is done and available for all to read and critique at: http://www.gargoylecc.com/~ringram/Linux+XFS-HOWTO.txt It does nothing for documenting filesystem maintenance or usage of the xfsdump and xfsrestore commands for backups. I think those should either go in a different document or they will come later. The other things on my todo list for this doc is to port it to ps, pdf, and html. Any suggestions for other things to add to that todo list are welcome. Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Sun Jan 21 21:15:19 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 21:15:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:46201 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 21:14:45 -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 VAA15375 for ; Sun, 21 Jan 2001 21:13:46 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13809 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 22 Jan 2001 16:14:18 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA63119 for ; Mon, 22 Jan 2001 16:13:33 +1100 (EST) Message-Id: <200101220513.QAA63119@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com X-URL: http://zoic.org/dxm Subject: ASSERT trip in XFS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 16:13:33 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing With T-o-T XFS, on IDE, no kio, SMP, no HIGHMEM, qa 042 fails in page_daemon: (related to recent "xfs_strategy" changes ?) (failed 2 out of 2 runs) XFS assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: xfs_trans.c, line: 335 kernel BUG at debug.c:48! Entering kdb (current=0xc7844000, pid 732) on processor 0 Panic: invalid operand due to panic @ 0xc8828da5 eax = 0x0000001a ebx = 0xc2690360 ecx = 0x00000001 edx = 0x00000000 esi = 0xfffffff1 edi = 0xc7845c24 esp = 0xc78459e8 eip = 0xc8828da5 ebp = 0xc78459f4 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc78459b4 [0]kdb> bt EBP EIP Function(args) 0xc78459f4 0xc8828da5 [xfs_support]assfail+0x2d (0xc89b1580, 0xc89b13d4, 0x14f) xfs_support .text 0xc8828060 0xc8828d78 0xc8828dac 0xc7845a10 0xc89830f6 [xfs]xfs_trans_mod_sb+0x142 (0xc2690360, 0x4, 0xfffffff1) xfs .text 0xc8926060 0xc8982fb4 0xc8983250 0xc7845a2c 0xc8926e50 [xfs]xfs_alloc_ag_vextent+0x278 (0xc7845c24, 0xc45e3000, 0x17de, 0x0) xfs .text 0xc8926060 0xc8926bd8 0xc8926e6c 0xc7845a64 0xc89297ae [xfs]xfs_alloc_vextent+0x21e (0xc7845c24) xfs .text 0xc8926060 0xc8929590 0xc8929a7c 0xc7845c74 0xc8939d7c [xfs]xfs_bmap_alloc+0x1930 (0xc7845da4) xfs .text 0xc8926060 0xc893844c 0xc893a04c 0xc7845df0 0xc893dff1 [xfs]xfs_bmapi+0x875 (0xc2690360, 0xc4d7b304, 0x1, 0x0, 0xf) xfs .text 0xc8926060 0xc893d77c 0xc893f118 0xc7845f24 0xc8998e7b [xfs]xfs_strategy+0x577 (0xc4d7b31c, 0x0, 0x0, 0x1000, 0x10002) xfs .text 0xc8926060 0xc8998904 0xc89992f0 0xc7845f5c 0xc8997039 [xfs]linvfs_pb_bmap+0xa5 (0xc4155440, 0x0, 0x0, 0x1000, 0xc7845f9c) xfs .text 0xc8926060 0xc8996f94 0xc8997048 0xc7845fb8 0xc8833623 [pagebuf]pagebuf_delalloc_convert+0x4b (0xc1171008, 0xc77b4000) pagebuf .text 0xc882e060 0xc88335d8 0xc883382c 0xc7845fec 0xc8833a20 [pagebuf]page_cleaner_daemon+0x1f4 pagebuf .text 0xc882e060 0xc883382c 0xc8833b00 0xc0107547 kernel_thread+0x23 [0]more> kernel .text 0xc0100000 0xc0107524 0xc010755c From owner-linux-xfs@oss.sgi.com Sun Jan 21 21:42:19 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 21:42:09 -0800 Received: from mail11.jump.net ([206.196.91.11]:442 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 21:41:55 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0M5fl400753; Sun, 21 Jan 2001 23:41:47 -0600 (CST) Message-ID: <3A6BC823.6BD97740@sgi.com> Date: Sun, 21 Jan 2001 23:41:55 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russel Ingram CC: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I haven't looked at this in depth yet, but I noticed: > Once that is done just add the initrd line in lilo.conf AND > append = "ramdisk_size=25000" > The default size is 4096 which isn't nearly large enough to hold xfs. The -g3 flag has been removed from the makefile, and the XFS module is now quite a bit smaller... I think Russell has a better idea of how big the ramdisk now needs to be, from our work with the RH installer - Russell? -Eric From owner-linux-xfs@oss.sgi.com Sun Jan 21 21:54:49 2001 Received: by oss.sgi.com id ; Sun, 21 Jan 2001 21:54:39 -0800 Received: from [160.94.232.55] ([160.94.232.55]:23562 "EHLO lupo.thebarn.com") by oss.sgi.com with ESMTP id ; Sun, 21 Jan 2001 21:54:25 -0800 Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id f0M5s8433122; Sun, 21 Jan 2001 23:54:08 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A6BCB38.F941D4A6@thebarn.com> Date: Sun, 21 Jan 2001 23:55:04 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Russel Ingram , linux-xfs@oss.sgi.com Subject: Re: Root XFS partition References: <3A6BC823.6BD97740@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Eric Sandeen wrote: > I haven't looked at this in depth yet, but I noticed: > > > Once that is done just add the initrd line in lilo.conf AND > > append = "ramdisk_size=25000" > > The default size is 4096 which isn't nearly large enough to hold xfs. > > The -g3 flag has been removed from the makefile, and the XFS module is > now quite a bit smaller... > > I think Russell has a better idea of how big the ramdisk now needs to > be, from our work with the RH installer - Russell? 2500 should suffice now, depending upon how many additional scsi modules are needed. > > > -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 22 00:21:11 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 00:20:52 -0800 Received: from bru5-smtp-out2.uunet.be ([194.7.1.6]:18859 "EHLO bru5-smtp-out2.uunet.be") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 00:20:27 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out2.uunet.be (8.9.3/8.9.1) with SMTP id JAA09024 for ; Mon, 22 Jan 2001 09:20:23 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id JAA16848 for ; Mon, 22 Jan 2001 09:23:09 +0100 (MET) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA02778 for ; Mon, 22 Jan 2001 09:19:50 +0100 Message-ID: <3A6BED26.5A9B854E@vum.be> Date: Mon, 22 Jan 2001 09:19:50 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: XFS beta4 image Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing SGkgYWxsLi4uDQoNCkkgaGF2ZSBpbnN0YWxsZWQgZnJlc2ggd2l0aCB0aGUgbGF0ZXN0IGlz byBpbWFnZSAuLi4gb24gYSBkZWxsIGxhcHRvcA0Kd2l0aCBvbmx5IGFuIGlkZSBkcml2ZS4N Cg0KSSBvcHRlZCBmb3IgMiBwYXJ0aXRpb25zIDogMSBsYXJnZSBYRlMgcGFydGl0aW9uIGZv ciAvIGFuZCBhIHN3YXAuDQoNCkl0IGluc3RhbGxlZCB0aGUgZmlyc3QgdGltZSAuLi4gcmVi b290ID0gbm8gcHJvYmxlbQ0KDQpldmVyeXRoaW5nIHdvcmtzIC4uLiBvbmx5IHNvbWUgcXVp cmtzIHdpdGggZGV2ZnMuLi4gYnV0IG5vdGhpbmcgdGhhdA0KY2FudCBiZSBzb2x2ZWQuDQoN Cg0KSSB0aGVuIGRpZCBhIHRlc3QgLi4uIHBvd2VyIGRvd24gd2l0aG91dCBzaHV0dGluZyBk b3duIC4uLiB4ZnMgY2FtZSB1cC4uDQpjaGVja2VkIG9uIGJvb3QgYW5kIGNvbnRpbnVlZCBi b290aW5nIC4uLg0KDQoNCnNvIC4uLiBpdCB3b3JrcyBmb3IgbWUgLi4uDQoNCg0KaGFyZHdh cmUgOiBEZWxsIExhdHRpdHVkZSBDUGkyNjYgd2l0aCA0RyBpZGUgZGlzaywgLi4uLiA2NCBN QiByYW0gLi4uLg0KDQoNCmhhdmVudCBkb25lIGFueSBzdHJlc3MgdGVzdGluZyAuLi4ueWV0 DQo= From owner-linux-xfs@oss.sgi.com Mon Jan 22 03:33:22 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 03:33:12 -0800 Received: from bru5-smtp-out1.uunet.be ([194.7.1.5]:62339 "EHLO bru5-smtp-out1.uunet.be") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 03:32:59 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out1.uunet.be (8.9.3/8.9.1) with SMTP id MAA23305 for ; Mon, 22 Jan 2001 12:32:56 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id MAA28096 for ; Mon, 22 Jan 2001 12:35:43 +0100 (MET) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id MAA02163 for ; Mon, 22 Jan 2001 12:32:23 +0100 Message-ID: <3A6C1A47.8FB8AE6A@vum.be> Date: Mon, 22 Jan 2001 12:32:23 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: problems with xfs ? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing b2sgLi4uDQoNCkkgZ290IGl0IHJ1bm5pbiBhcyByb290IGZzIG9uIGEgbGFwdG9wIC4uLiB3 aXRoIHhmcyBhcyB0aGUgb25seQ0KZmlsZXN5c3RlbSBpbiB1c2UuLi4NCg0Kbm93IEkgdGhp bmsgSSBuZWVkIHRvIHJ1biB4ZnNfcmVwYWlyIC4uLiBidXQgSSBjYW4gbm90IC4uLiAgIG5l ZWRzDQp1bm1vdW50ZWQgZnMuLi4uIHdpdGggcm9vdCBmcyAuLi4gcHJvYmxlbQ0KDQpJdCBi b290cyBvayAuLi4gdHJpZXMgdG8gcmVwYWlyIC4uLiBzYXlzIGl0IHdpbGwgcmVwYWlyIC4u LiBidXQgaXQncyBub3QNCmluIGEgY29uc2lzdGVudCBzdGF0ZSAuLi4geGZzX3JlcGFpciAt biAgcmV0dXJucyBhIDEgLi4uIHN0YXRpbmcgdGhhdA0KdGhlcmUgaXMgc3RpbGwgYSBwcm9i bGVtIHRvIGJlIGZpeGVkLi4uDQoNCg0KYW55IGlkZWFzIC4uLiB3aXRob3V0IGhhdmluZyB0 byByZWJvb3QgaW4gc2luZ2xlIHVzZXIgbW9kZSBmcm9tIHRoZSBDRA0KLi4uIDopDQo= From owner-linux-xfs@oss.sgi.com Mon Jan 22 03:57:21 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 03:57:02 -0800 Received: from hermes.mixx.net ([212.84.196.2]:62985 "HELO hermes.mixx.net") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 03:56:41 -0800 Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id B144EF80A for ; Mon, 22 Jan 2001 12:56:38 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id 8B13F2CA6F; Mon, 22 Jan 2001 12:56:38 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.list.sgi.xfs Subject: Re: problems with xfs ? Date: 22 Jan 2001 11:56:38 GMT Organization: innominate AG, Berlin, Germany Lines: 32 Distribution: local Message-ID: References: <3A6C1A47.8FB8AE6A@vum.be> Reply-To: thomas.graichen@innominate.com X-Trace: mate.bln.innominate.de 980164598 3424 10.0.0.31 (22 Jan 2001 11:56:38 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS (i686)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing kris buggenhout wrote: > ok ... > I got it runnin as root fs on a laptop ... with xfs as the only > filesystem in use... > now I think I need to run xfs_repair ... but I can not ... needs > unmounted fs.... with root fs ... problem > It boots ok ... tries to repair ... says it will repair ... but it's not > in a consistent state ... xfs_repair -n returns a 1 ... stating that > there is still a problem to be fixed... > any ideas ... without having to reboot in single user mode from the CD > ... :) if its not too late for that http://innominate.org/~graichen/projects/miniroot/0.6/ thats exacly what i did it for :-) t p.s.: ... oh but it needs a ext2 /boot ... -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com From owner-linux-xfs@oss.sgi.com Mon Jan 22 05:42:41 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 05:42:22 -0800 Received: from bru5-smtp-out1.uunet.be ([194.7.1.5]:18411 "EHLO bru5-smtp-out1.uunet.be") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 05:42:03 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out1.uunet.be (8.11.2/8.11.2) with SMTP id f0MDg1V00462 for ; Mon, 22 Jan 2001 14:42:01 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id OAA12026 for ; Mon, 22 Jan 2001 14:44:47 +0100 (MET) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id OAA04989 for ; Mon, 22 Jan 2001 14:41:26 +0100 Message-ID: <3A6C3886.C6700125@vum.be> Date: Mon, 22 Jan 2001 14:41:26 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: troubles with xfs Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Li4uIGhtbW0gc2VlbWVkIHRvIGJlIG9wdGltaXN0aWMuLi4NCg0KSSB0cmllZCB0byByZXBh aXIgdGhlIHJvb3Qgd2l0aCB4ZnMgcmVwYWlyIC4uLiB0aGF0IHdvcmtlZCAuLi4gYnV0IHRo ZQ0Kc2Vjb25kIHRpbWUgLi4uIGl0IG1vdmVkIHNvbWUgdGhpbmdzIHRvIGxvc3QrZm91bmQg bm93IEkgZ2V0IGFuDQp1bmJvb3RhYmxlIHN5c3RlbS4uLg0KDQppdCBib290cyB1cCB1bnRp bCAgICAidHVybmluZyBvbiB1c2VyIGFuZCBncm91cCBxdW90YXMgZm9yIGxvY2FsDQpmaWxl c3lzdGVtcyAiDQp0aGVuIEkgZ2V0ICAgICAiL2V0Yy9yYy5zeXNpbml0OiBybTpjb21tYW5k IG5vdCBmb3VuZCINCg0KDQpJIGhhdmUgdG8gcmVpbnN0YWxsIC4uLiAgICAgICAgICAgICAg ICAgOigNCg0KDQp0aGlzIGlzIG9uIGEgbGFwdG9wIHdpdGggWEZTIGJldGE0IGlzbyAoUHJl IFJlbGVhc2UgaXQgc2F5cyBvbiB0aGUgQ0QpDQo= From owner-linux-xfs@oss.sgi.com Mon Jan 22 08:35:52 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 08:35:33 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35447 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 08:35:27 -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 IAA03356 for ; Mon, 22 Jan 2001 08:44:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA546579; Mon, 22 Jan 2001 10:34:09 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA46879; Mon, 22 Jan 2001 10:34:09 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MGYc111617; Mon, 22 Jan 2001 10:34:38 -0600 Message-Id: <200101221634.f0MGYc111617@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: kris buggenhout cc: "linux-xfs@oss.sgi.com" Subject: Re: troubles with xfs In-Reply-To: Message from kris buggenhout of "Mon, 22 Jan 2001 14:41:26 +0100." <3A6C3886.C6700125@vum.be> Date: Mon, 22 Jan 2001 10:34:38 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing gast6@vum.be said: >> ... hmmm seemed to be optimistic... >> I tried to repair the root with xfs repair ... that worked ... but the >> second time ... it moved some things to lost+found now I get an >> unbootable system... >> >> it boots up until "turning on user and group quotas for local >> filesystems " then I get "/etc/rc.sysinit: rm:command not found" >> >> I have to reinstall ... :( >> >> this is on a laptop with XFS beta4 iso (Pre Release it says on the CD) >> Can you give a more complete description of what you did? You say you tried to repair the root, was this from the miniroot? Also, as a rule, xfs_repair -n on a running filesystem can give confusing and invalid results. Repair is reading data direct from the disk and will not see anything still in buffers within the kernel, this can result in erroneous reports of corruption. Also running repair on a filesystem which was not cleanly shutdown and has not been remounted since then can also produce worse results than remounting the filesystem to replay the log, then unmounting and running repair. Finally, repair puts unlinked files in a lost+found directory, but if files are left there and repair is run again, it will unlink lost+found and find the files as unlinked again. The thing to do is to move the recovered files somewhere else before running repair again. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 22 08:54:22 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 08:54:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:50812 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 08:53:52 -0800 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA14027 for ; Mon, 22 Jan 2001 08:52:54 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.66.65]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA26376 for ; Mon, 22 Jan 2001 08:56:07 -0800 (PST) Received: from sgi.com (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 23675845B5 for ; Mon, 22 Jan 2001 08:52:12 -0800 (PST) Message-ID: <3A6C653C.B1983FE7@sgi.com> Date: Mon, 22 Jan 2001 08:52:12 -0800 From: Florin Andrei Organization: SGI X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-lvs-1.0.3-reiserfs-3.5.29 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs and reiserfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Is it possible right now to have both XFS and ReiserFS in the kernel? (and maybe use them simultaneously, on different partitions) -- Florin Andrei "Saying everything is a database is saying nothing at all and certainly will not improve communication with others. Database, database database. Database! See?" (Marc Lehmann) From owner-linux-xfs@oss.sgi.com Mon Jan 22 08:59:03 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 08:58:52 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:42058 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 08:58:40 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08768 for ; Mon, 22 Jan 2001 08:58:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA544860; Mon, 22 Jan 2001 10:57:16 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA79394; Mon, 22 Jan 2001 10:57:16 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MGvjd11716; Mon, 22 Jan 2001 10:57:45 -0600 Message-Id: <200101221657.f0MGvjd11716@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Florin Andrei cc: linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs In-Reply-To: Message from Florin Andrei of "Mon, 22 Jan 2001 08:52:12 PST." <3A6C653C.B1983FE7@sgi.com> Date: Mon, 22 Jan 2001 10:57:45 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > Is it possible right now to have both XFS and ReiserFS in the kernel? > (and maybe use them simultaneously, on different partitions) > > -- > Florin Andrei It should be - people have done this in the past. Until we move up to 2.4.1 in the xfs tree, it is going to involve some patching of source on your part. The best bet is probably to take the xfs tree and apply a reiserfs patch to it. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:04:22 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:04:03 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:16462 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:03:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04659 for ; Mon, 22 Jan 2001 09:03:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA547017 for ; Mon, 22 Jan 2001 11:02:39 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA73768 for ; Mon, 22 Jan 2001 11:02:39 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MH38h12510; Mon, 22 Jan 2001 11:03:08 -0600 Message-Id: <200101221703.f0MH38h12510@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) Date: Mon, 22 Jan 2001 11:03:08 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I am wondering if this will help out in the 'XFS and RAID5 Aren't Playing Well Together' issue? Steve ------- Forwarded Message Date: Mon, 22 Jan 2001 19:36:30 +0000 From: Edward To: Neil Brown cc: Otto Meier , Holger Kiehl , Hans Reiser , Ed Tomlinson , Nils Rennebarth , Manfred Spraul , David Willmore , Linus Torvalds , Alan Cox , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ Neil Brown wrote: > > There have been assorted reports of filesystem corruption on raid5 in > 2.4.0, and I have finally got a patch - see below. > I don't know if it addresses everybody's problems, but it fixed a very > really problem that is very reproducable. > > The problem is that parity can be calculated wrongly when doing a > read-modify-write update cycle. If you have a fully functional, you > wont notice this problem as the parity block is never used to return > data. But if you have a degraded array, you will get corruption very > quickly. > So I think this will solve the reported corruption with ext2fs, as I > think they were mostly on degradred arrays. I have no idea whether it > will address the reiserfs problems as I don't think anybody reporting > those problems described their array. But we deal with a fully functional one. Nevertheless this patch fixed reiserfs corruption.. Thanks. Edward. > > In any case, please apply, and let me know of any further problems. > > --- ./drivers/md/raid5.c 2001/01/21 04:01:57 1.1 > +++ ./drivers/md/raid5.c 2001/01/21 20:36:05 1.2 > @@ -714,6 +714,11 @@ > break; > } > spin_unlock_irq(&conf->device_lock); > + if (count>1) { > + xor_block(count, bh_ptr); > + count = 1; > + } > + > for (i = disks; i--;) > if (chosen[i]) { > struct buffer_head *bh = sh->bh_cache[i]; - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ------- End of Forwarded Message From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:12:53 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:12:33 -0800 Received: from 209-161-7-106.gargoylecc.com ([209.161.7.106]:26240 "EHLO roujin.gargoylecc.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:12:30 -0800 Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [209.161.7.106]) by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id BAA07525 for ; Tue, 23 Jan 2001 01:21:20 -0700 Date: Tue, 23 Jan 2001 01:21:20 -0700 (MST) From: Russel Ingram To: linux-xfs@oss.sgi.com Subject: Re: Root XFS partition In-Reply-To: <3A6BCB38.F941D4A6@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 21 Jan 2001, Russell Cattelan wrote: > Date: Sun, 21 Jan 2001 23:55:04 -0600 > From: Russell Cattelan > To: Eric Sandeen > Cc: Russel Ingram , linux-xfs@oss.sgi.com > Subject: Re: Root XFS partition > > Eric Sandeen wrote: > > > I haven't looked at this in depth yet, but I noticed: > > > > > Once that is done just add the initrd line in lilo.conf AND > > > append = "ramdisk_size=25000" > > > The default size is 4096 which isn't nearly large enough to hold xfs. > > > > The -g3 flag has been removed from the makefile, and the XFS module is > > now quite a bit smaller... > > > > I think Russell has a better idea of how big the ramdisk now needs to > > be, from our work with the RH installer - Russell? > > 2500 should suffice now, depending upon how many additional scsi > modules are needed. > > > > > > > -Eric That was a direct quote from an email message so it will stay the same (unless making it that large is going to cause problems -- then I will make an addendum to the quote or something). I will change it if/when I get a chance to try it for myself. Thanx for the info, tho. Russ -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:16:33 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:16:23 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:6411 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:16:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA19153 for ; Mon, 22 Jan 2001 09:15:07 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA30373; Mon, 22 Jan 2001 11:14:48 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0MHDmd26826; Mon, 22 Jan 2001 11:13:48 -0600 Message-ID: <3A6C6A4C.E71547C1@thebarn.com> Date: Mon, 22 Jan 2001 11:13:48 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <200101221657.f0MGvjd11716@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > If your interested I could send you an XFS patch that can be applied to a 2.4.1pre8 tree. I haven't tested it yet but it does compile and I think I got the merge correct. > > > > Is it possible right now to have both XFS and ReiserFS in the kernel? > > (and maybe use them simultaneously, on different partitions) > > > > -- > > Florin Andrei > > It should be - people have done this in the past. Until we move up to > 2.4.1 in the xfs tree, it is going to involve some patching of source > on your part. The best bet is probably to take the xfs tree and apply > a reiserfs patch to it. > > Steve -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:28:53 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:28:33 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43903 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:28:26 -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 JAA07673 for ; Mon, 22 Jan 2001 09:37:22 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA541073; Mon, 22 Jan 2001 11:27:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA94725; Mon, 22 Jan 2001 11:27:05 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MHRYv12660; Mon, 22 Jan 2001 11:27:34 -0600 Message-Id: <200101221727.f0MHRYv12660@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Moore cc: linux-xfs@oss.sgi.com Subject: Re: ASSERT trip in XFS In-Reply-To: Message from Daniel Moore of "Mon, 22 Jan 2001 16:13:33 +1100." <200101220513.QAA63119@clouds.melbourne.sgi.com> Date: Mon, 22 Jan 2001 11:27:34 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > With T-o-T XFS, on IDE, no kio, SMP, no HIGHMEM, qa 042 fails in page_daemon: > (related to recent "xfs_strategy" changes ?) > > (failed 2 out of 2 runs) I cannot make this test fail for me, but I did manage to hit this via other means. I will dig into it, but yes the strategy change looks like a candidate for causing this. More to follow.... Steve > > > XFS assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: xfs_trans.c, > > line: 335 > kernel BUG at debug.c:48! > > Entering kdb (current=0xc7844000, pid 732) on processor 0 Panic: invalid > operand > due to panic @ 0xc8828da5 > eax = 0x0000001a ebx = 0xc2690360 ecx = 0x00000001 edx = 0x00000000 > esi = 0xfffffff1 edi = 0xc7845c24 esp = 0xc78459e8 eip = 0xc8828da5 > ebp = 0xc78459f4 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc78459b4 > [0]kdb> bt > EBP EIP Function(args) > 0xc78459f4 0xc8828da5 [xfs_support]assfail+0x2d (0xc89b1580, 0xc89b13d4, 0x14 > f) > xfs_support .text 0xc8828060 0xc8828d78 > 0xc8828dac > 0xc7845a10 0xc89830f6 [xfs]xfs_trans_mod_sb+0x142 (0xc2690360, 0x4, 0xfffffff > 1) > xfs .text 0xc8926060 0xc8982fb4 0xc8983250 > 0xc7845a2c 0xc8926e50 [xfs]xfs_alloc_ag_vextent+0x278 (0xc7845c24, 0xc45e3000 > , > 0x17de, 0x0) > xfs .text 0xc8926060 0xc8926bd8 0xc8926e6c > 0xc7845a64 0xc89297ae [xfs]xfs_alloc_vextent+0x21e (0xc7845c24) > xfs .text 0xc8926060 0xc8929590 0xc8929a7c > 0xc7845c74 0xc8939d7c [xfs]xfs_bmap_alloc+0x1930 (0xc7845da4) > xfs .text 0xc8926060 0xc893844c 0xc893a04c > 0xc7845df0 0xc893dff1 [xfs]xfs_bmapi+0x875 (0xc2690360, 0xc4d7b304, 0x1, 0x0, > > 0xf) > xfs .text 0xc8926060 0xc893d77c 0xc893f118 > 0xc7845f24 0xc8998e7b [xfs]xfs_strategy+0x577 (0xc4d7b31c, 0x0, 0x0, 0x1000, > 0x10002) > xfs .text 0xc8926060 0xc8998904 0xc89992f0 > 0xc7845f5c 0xc8997039 [xfs]linvfs_pb_bmap+0xa5 (0xc4155440, 0x0, 0x0, 0x1000, > > 0xc7845f9c) > xfs .text 0xc8926060 0xc8996f94 0xc8997048 > 0xc7845fb8 0xc8833623 [pagebuf]pagebuf_delalloc_convert+0x4b (0xc1171008, > 0xc77b4000) > pagebuf .text 0xc882e060 0xc88335d8 0xc883382c > 0xc7845fec 0xc8833a20 [pagebuf]page_cleaner_daemon+0x1f4 > pagebuf .text 0xc882e060 0xc883382c 0xc8833b00 > 0xc0107547 kernel_thread+0x23 > [0]more> > kernel .text 0xc0100000 0xc0107524 0xc010755c > > > From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:28:53 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:28:44 -0800 Received: from mail.connex.com ([216.100.236.3]:28423 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:28:30 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 09:25:07 -0800 Message-ID: From: Scott Smyth To: 'Steve Lord ' , "'linux-xfs@oss.sgi.com '" Subject: RE: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) Date: Mon, 22 Jan 2001 09:25:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Steve; Several issues are coming up in debugging the RAID5 and XFS issue(s). We will try this patch, but there are larger issues as well one of our engineers flushed out with Martin and Neils' help. However, this will solve part of them. There is still the issue of doing 512-byte writes and RAID 5 only does 1024. We are working on it with Neil and Martin with two of our engineers: Danny Cox (who sent this email), dcox@connex.com; and Robert Lasirona, rlasirona@connex.com. See the email below. Danny sent a patch to allow mkfs.xfs and mounting after play well while it is resyncing that we are trying now and will send on to the list. BTW, why are 512-byte writes done? thanks, Scott Neil Brown wrote: > > On Friday January 19, danscox@mindspring.com wrote: > > Neil, > > > > > > I'm Danny Cox, one of Scott's engineers. I have some insight: > > sometimes, XFS writes to the block device using a block size of 512 > > bytes. This is apparently what gives MD/RAID5 problems. For example, > > in raid5_sync_request, the last statement is: > > > > return (bufsize>>10)-redone; > > > > Well, if bufsize (which comes from sh->size) is 512, then bufsize>>10 is > > 0! This causes an infinite loop in md_do_sync(). Martin Petersen @ > > Linuxcare also confirms that MD/RAID5 doesn't work with 512 byte blocks, > > and said he'll contact you also, to see how you feel about it. > > > > If I can be of further assistance, please let me know. > > > > Thanks for your time! > > Looks like a good call to me. It definately would have problems with > a 512 byte block size. > > The resync code has always been done in multiples of 1K, and as I > wasn't really sure why, I didn't change it. But now I am a lot more > familiar with all the code and I am quite confident that changing it > to work in 512 byte units would be fine. Probably make various bits > of code cleaner too. > I will put togethe a patch just as soon as I resolve all the > filesystem corruptions.... unless you beat me to it. > > Thanks, > NeilBrown Sincerely, Scott -- Scott Smyth 408-605-4743 -----Original Message----- From: Steve Lord To: linux-xfs@oss.sgi.com Sent: 1/22/01 9:03 AM Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) I am wondering if this will help out in the 'XFS and RAID5 Aren't Playing Well Together' issue? Steve ------- Forwarded Message Date: Mon, 22 Jan 2001 19:36:30 +0000 From: Edward To: Neil Brown cc: Otto Meier , Holger Kiehl , Hans Reiser , Ed Tomlinson , Nils Rennebarth , Manfred Spraul , David Willmore , Linus Torvalds , Alan Cox , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ Neil Brown wrote: > > There have been assorted reports of filesystem corruption on raid5 in > 2.4.0, and I have finally got a patch - see below. > I don't know if it addresses everybody's problems, but it fixed a very > really problem that is very reproducable. > > The problem is that parity can be calculated wrongly when doing a > read-modify-write update cycle. If you have a fully functional, you > wont notice this problem as the parity block is never used to return > data. But if you have a degraded array, you will get corruption very > quickly. > So I think this will solve the reported corruption with ext2fs, as I > think they were mostly on degradred arrays. I have no idea whether it > will address the reiserfs problems as I don't think anybody reporting > those problems described their array. But we deal with a fully functional one. Nevertheless this patch fixed reiserfs corruption.. Thanks. Edward. > > In any case, please apply, and let me know of any further problems. > > --- ./drivers/md/raid5.c 2001/01/21 04:01:57 1.1 > +++ ./drivers/md/raid5.c 2001/01/21 20:36:05 1.2 > @@ -714,6 +714,11 @@ > break; > } > spin_unlock_irq(&conf->device_lock); > + if (count>1) { > + xor_block(count, bh_ptr); > + count = 1; > + } > + > for (i = disks; i--;) > if (chosen[i]) { > struct buffer_head *bh = sh->bh_cache[i]; - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ------- End of Forwarded Message From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:38:13 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:38:03 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:58212 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:38:02 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07606 for ; Mon, 22 Jan 2001 09:38:01 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA547078; Mon, 22 Jan 2001 11:36:45 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA94227; Mon, 22 Jan 2001 11:36:45 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MHbDR12676; Mon, 22 Jan 2001 11:37:13 -0600 Message-Id: <200101221737.f0MHbDR12676@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Scott Smyth cc: "'Steve Lord '" , "'linux-xfs@oss.sgi.com '" Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) In-Reply-To: Message from Scott Smyth of "Mon, 22 Jan 2001 09:25:06 PST." Date: Mon, 22 Jan 2001 11:37:13 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hi Steve; > > Several issues are coming up in debugging the RAID5 > and XFS issue(s). We will try this patch, but there are > larger issues as well one of our engineers flushed out > with Martin and Neils' help. However, this will solve > part of them. > > There is still the issue of doing 512-byte writes and > RAID 5 only does 1024. We are working on it with Neil > and Martin with two of our engineers: Danny Cox (who sent > this email), dcox@connex.com; and Robert Lasirona, > rlasirona@connex.com. See the email below. > > Danny sent a patch to allow mkfs.xfs and mounting after > play well while it is resyncing that we are trying now > and will send on to the list. > > BTW, why are 512-byte writes done? > > thanks, Scott > 512 byte writes are done by XFS because we have some metadata which is always 512 bytes long - there are 4 fields at the head of each allocation group which are fixed at this size. The superblock and some headers for free block and inode trees. Because of the transactional nature of xfs, there are conceivably cases where one chunk of 512 bytes must be written to disk (because it is at the tail of the log and we need more log space), and the other 512 bytes in the same 1K chunk must not be (because it is modified in memory and not written to disk in the log yet). Having said all that, I am not totally sure how it fits in with this: SSmyth@connex.com said: >> Raid 5 resync is done in "multiples of 1K", but XFS appears to need >> 512-byte resyncs as the base unit. Sorry for the terse explanation >> that probably seemed unclear. I have not looked at the raid5 code, so I don't know at what level it is doing the resync. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:48:42 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:48:23 -0800 Received: from tux.mkp.net ([130.225.60.11]:7174 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:48:02 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14Kl3u-0008Dc-00; Mon, 22 Jan 2001 18:47:27 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id MAA11313; Mon, 22 Jan 2001 12:47:32 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Scott Smyth Cc: linux-xfs@oss.sgi.com, neilb@cse.unsw.edu.au Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 22 Jan 2001 12:47:31 -0500 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing [MD vs. 512 byte sectors] >> Looks like a good call to me. It definately would have problems >> with a 512 byte block size. >> >> The resync code has always been done in multiples of 1K, and as I >> wasn't really sure why, I didn't change it. But now I am a lot >> more familiar with all the code and I am quite confident that >> changing it to work in 512 byte units would be fine. Looks good here. I'm beating on it right now and will send out a patch later today. >> Probably make various bits of code cleaner too. Yep. There are like a gazillion places where the code converts between 1K blocks and sectors. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Mon Jan 22 09:49:43 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 09:49:23 -0800 Received: from mail.connex.com ([216.100.236.3]:1290 "EHLO cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 09:49:18 -0800 Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 09:30:49 -0800 Message-ID: From: Scott Smyth To: ''Steve Lord ' ' , "''linux-xfs@oss.sgi.com ' '" Subject: RE: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) Date: Mon, 22 Jan 2001 09:30:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing For clarification: > There is still the issue of doing 512-byte > writes and RAID 5 only does 1024. Raid 5 resync is done in "multiples of 1K", but XFS appears to need 512-byte resyncs as the base unit. Sorry for the terse explanation that probably seemed unclear. Scott -----Original Message----- From: Scott Smyth To: 'Steve Lord '; 'linux-xfs@oss.sgi.com ' Sent: 1/22/01 9:25 AM Subject: RE: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) Hi Steve; Several issues are coming up in debugging the RAID5 and XFS issue(s). We will try this patch, but there are larger issues as well one of our engineers flushed out with Martin and Neils' help. However, this will solve part of them. There is still the issue of doing 512-byte writes and RAID 5 only does 1024. We are working on it with Neil and Martin with two of our engineers: Danny Cox (who sent this email), dcox@connex.com; and Robert Lasirona, rlasirona@connex.com. See the email below. Danny sent a patch to allow mkfs.xfs and mounting after play well while it is resyncing that we are trying now and will send on to the list. BTW, why are 512-byte writes done? thanks, Scott Neil Brown wrote: > > On Friday January 19, danscox@mindspring.com wrote: > > Neil, > > > > > > I'm Danny Cox, one of Scott's engineers. I have some insight: > > sometimes, XFS writes to the block device using a block size of 512 > > bytes. This is apparently what gives MD/RAID5 problems. For example, > > in raid5_sync_request, the last statement is: > > > > return (bufsize>>10)-redone; > > > > Well, if bufsize (which comes from sh->size) is 512, then bufsize>>10 is > > 0! This causes an infinite loop in md_do_sync(). Martin Petersen @ > > Linuxcare also confirms that MD/RAID5 doesn't work with 512 byte blocks, > > and said he'll contact you also, to see how you feel about it. > > > > If I can be of further assistance, please let me know. > > > > Thanks for your time! > > Looks like a good call to me. It definately would have problems with > a 512 byte block size. > > The resync code has always been done in multiples of 1K, and as I > wasn't really sure why, I didn't change it. But now I am a lot more > familiar with all the code and I am quite confident that changing it > to work in 512 byte units would be fine. Probably make various bits > of code cleaner too. > I will put togethe a patch just as soon as I resolve all the > filesystem corruptions.... unless you beat me to it. > > Thanks, > NeilBrown Sincerely, Scott -- Scott Smyth 408-605-4743 -----Original Message----- From: Steve Lord To: linux-xfs@oss.sgi.com Sent: 1/22/01 9:03 AM Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) I am wondering if this will help out in the 'XFS and RAID5 Aren't Playing Well Together' issue? Steve ------- Forwarded Message Date: Mon, 22 Jan 2001 19:36:30 +0000 From: Edward To: Neil Brown cc: Otto Meier , Holger Kiehl , Hans Reiser , Ed Tomlinson , Nils Rennebarth , Manfred Spraul , David Willmore , Linus Torvalds , Alan Cox , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ Neil Brown wrote: > > There have been assorted reports of filesystem corruption on raid5 in > 2.4.0, and I have finally got a patch - see below. > I don't know if it addresses everybody's problems, but it fixed a very > really problem that is very reproducable. > > The problem is that parity can be calculated wrongly when doing a > read-modify-write update cycle. If you have a fully functional, you > wont notice this problem as the parity block is never used to return > data. But if you have a degraded array, you will get corruption very > quickly. > So I think this will solve the reported corruption with ext2fs, as I > think they were mostly on degradred arrays. I have no idea whether it > will address the reiserfs problems as I don't think anybody reporting > those problems described their array. But we deal with a fully functional one. Nevertheless this patch fixed reiserfs corruption.. Thanks. Edward. > > In any case, please apply, and let me know of any further problems. > > --- ./drivers/md/raid5.c 2001/01/21 04:01:57 1.1 > +++ ./drivers/md/raid5.c 2001/01/21 20:36:05 1.2 > @@ -714,6 +714,11 @@ > break; > } > spin_unlock_irq(&conf->device_lock); > + if (count>1) { > + xor_block(count, bh_ptr); > + count = 1; > + } > + > for (i = disks; i--;) > if (chosen[i]) { > struct buffer_head *bh = sh->bh_cache[i]; - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ------- End of Forwarded Message From owner-linux-xfs@oss.sgi.com Mon Jan 22 10:31:33 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 10:31:23 -0800 Received: from [209.101.91.34] ([209.101.91.34]:28176 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 10:31:02 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id OAA20440; Mon, 22 Jan 2001 14:44:58 -0500 Message-ID: <3A6C7E32.F5854394@compro.net> Date: Mon, 22 Jan 2001 13:38:43 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <3A6C653C.B1983FE7@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Florin Andrei wrote: > > Is it possible right now to have both XFS and ReiserFS in the kernel? > (and maybe use them simultaneously, on different partitions) > > -- > Florin Andrei > "Saying everything is a database is saying nothing at all > and certainly will not improve communication with others. > Database, database database. Database! See?" (Marc Lehmann) Just yesterday I got it working. You must apply the reiser patch first then the XFS patch. I now have a 17g resier and a 17g xfs partition on my system coexsisting. I just finished last night and haven't really tested it much. 2 problems that I am having are, first the 2gb LFS isn't working with the reiser but does work with the XFS. The second problem is with the xfs. It may show up with the reiser also once I figure out the 2gb file size problem. When I do an ls, any file that is larger the 2gb gives some message about something too large to stat. The file is there and I can actually read it. (JUST a large tar ball). You want to start with the vanilla 2.4.0 sources and what ever updates it requires. (See Doc/Changes), apply the reiser first the the xfs patches. While I'm here does anyone know anything about the 2 problems I descibed above. 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) 2. On an XFS fs, doing an ls in a directory that has a file larger then 2+gb gives a message about to large to stat. -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Mon Jan 22 10:44:46 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 10:44:36 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:7219 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 10:44:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA07762 for ; Mon, 22 Jan 2001 10:43:15 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA548523; Mon, 22 Jan 2001 12:42:48 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA87656; Mon, 22 Jan 2001 12:42:48 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MIhG412765; Mon, 22 Jan 2001 12:43:17 -0600 Message-Id: <200101221843.f0MIhG412765@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: markh@compro.net cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs In-Reply-To: Message from Mark Hounschell of "Mon, 22 Jan 2001 13:38:43 EST." <3A6C7E32.F5854394@compro.net> Date: Mon, 22 Jan 2001 12:43:16 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > 2. On an XFS fs, doing an ls in a directory that has a file larger then > 2+gb gives a message about to large to stat. > You need a user space with LFS support, this error is almost certainly coming out of userspace. Something like a recent redhat release will not exhibit this problem. Steve > > -- > Mark Hounschell > markh@compro.net From owner-linux-xfs@oss.sgi.com Mon Jan 22 10:53:26 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 10:53:17 -0800 Received: from edge.coltex.nl ([194.151.97.115]:53008 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 10:53:05 -0800 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id f0MIqrZ29819; Mon, 22 Jan 2001 19:52:57 +0100 Message-Id: <4.3.2.7.2.20010122194858.037abad8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jan 2001 19:50:36 +0100 To: markh@compro.net From: Seth Mos Subject: Re: xfs and reiserfs Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing At 13:38 22-1-2001 -0500, you wrote: >Florin Andrei wrote: > > > > Is it possible right now to have both XFS and ReiserFS in the > kernel? > > (and maybe use them simultaneously, on different partitions) > > > > -- > > Florin Andrei > > "Saying everything is a database is saying nothing at all > > and certainly will not improve communication with others. > > Database, database database. Database! See?" (Marc Lehmann) > >Just yesterday I got it working. You must apply the reiser patch first >then the XFS patch. I now have a 17g resier and a 17g xfs partition on >my >system coexsisting. I just finished last night and haven't really tested >it much. 2 problems that I am having are, first the 2gb LFS isn't >working >with the reiser but does work with the XFS. The second problem is >with the xfs. It may show up with the reiser also once I figure out the >2gb file size problem. When I do an ls, any file that is larger the 2gb >gives some message about something too large to stat. The file is there >and I can actually read it. (JUST a large tar ball). You want to start >with the vanilla 2.4.0 sources and what ever updates it requires. (See >Doc/Changes), apply the reiser first the the xfs patches. > While I'm here does anyone know anything about the 2 problems I >descibed above. > >1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) >2. On an XFS fs, doing an ls in a directory that has a file larger then > 2+gb gives a message about to large to stat. I can't comment on reiserfs, I have not used that in a while. What distribution are you using, and more specific. The glibc version. You will need a recent glibc for the LFS AFAIK. [seth@lsautom large]$ ll -h total 2.9G -rw-r--r-- 1 seth staff 2.9G Jan 22 19:48 largefile.bin [seth@lsautom large]$ This is on a redhat 7 glibc 2.2 system Bye >-- >Mark Hounschell >markh@compro.net -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Mon Jan 22 10:56:16 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 10:55:56 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2063 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 10:55:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04619 for ; Mon, 22 Jan 2001 11:04:47 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA36649; Mon, 22 Jan 2001 12:54:34 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0MIrYd27074; Mon, 22 Jan 2001 12:53:34 -0600 Message-ID: <3A6C81AD.2E66A128@thebarn.com> Date: Mon, 22 Jan 2001 12:53:33 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Scott Smyth , "'linux-xfs@oss.sgi.com '" Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) References: <200101221737.f0MHbDR12676@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: Also Note: all of XFS's meta data writes when using LVM or MD devices should be in 512byte chunks. The switching sizes messeages is a bit weird as no size should be anything but 512 (meta data) or 4096 (file data) > > > Hi Steve; > > > > Several issues are coming up in debugging the RAID5 > > and XFS issue(s). We will try this patch, but there are > > larger issues as well one of our engineers flushed out > > with Martin and Neils' help. However, this will solve > > part of them. > > > > There is still the issue of doing 512-byte writes and > > RAID 5 only does 1024. We are working on it with Neil > > and Martin with two of our engineers: Danny Cox (who sent > > this email), dcox@connex.com; and Robert Lasirona, > > rlasirona@connex.com. See the email below. > > > > Danny sent a patch to allow mkfs.xfs and mounting after > > play well while it is resyncing that we are trying now > > and will send on to the list. > > > > BTW, why are 512-byte writes done? > > > > thanks, Scott > > > > 512 byte writes are done by XFS because we have some metadata which is always > 512 bytes long - there are 4 fields at the head of each allocation group which > are fixed at this size. The superblock and some headers for free block and > inode trees. > > Because of the transactional nature of xfs, there are conceivably cases > where one chunk of 512 bytes must be written to disk (because it is at > the tail of the log and we need more log space), and the other 512 bytes > in the same 1K chunk must not be (because it is modified in memory and > not written to disk in the log yet). > > Having said all that, I am not totally sure how it fits in with this: > > SSmyth@connex.com said: > >> Raid 5 resync is done in "multiples of 1K", but XFS appears to need > >> 512-byte resyncs as the base unit. Sorry for the terse explanation > >> that probably seemed unclear. > > I have not looked at the raid5 code, so I don't know at what level it > is doing the resync. > > Steve -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Jan 22 10:57:26 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 10:57:20 -0800 Received: from pike.sover.net ([209.198.87.34]:61155 "EHLO pike.sover.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 10:57:01 -0800 Received: from [192.168.1.3] (pm1a20.stj.sover.net [209.198.94.20]) by pike.sover.net (8.9.3/8.9.3) with ESMTP id NAA12990; Mon, 22 Jan 2001 13:56:17 -0500 (EST) Comments: SoVerNet Verification (on pike.sover.net) [192.168.1.3] from pm1a20.stj.sover.net [209.198.94.20] 209.198.94.20 Mon, 22 Jan 2001 13:56:17 -0500 (EST) Date: Mon, 22 Jan 2001 13:54:17 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Mark Hounschell cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs In-Reply-To: <3A6C7E32.F5854394@compro.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 22 Jan 2001, Mark Hounschell wrote: > While I'm here does anyone know anything about the 2 problems I > descibed above. > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > 2. On an XFS fs, doing an ls in a directory that has a file larger then > 2+gb gives a message about to large to stat. If I remember correctly, on linux x86, i.e. 32-bit linux, the VFS layer is still 32 bit. this means that no matter XFS's or reisers limits, you are limited to 2gb for files. Redhat has released a fix to increase that limit to 4 or 8gb, I *think* in their "professional" kernels or whatever. I also believe that SGI's development team is working with kernel developers for a workaround so we can have a 64-bit VFS layer, thus truely being able to exploit XFS's (and other fs's) ability. I have heard from friends (very smart friends with nice boxes) that even old ext2's limit is not 2gb, that it's a VFS thing. they claim that on a 64-bit arch. they can exceed the 2gb file size limit no problem. Ponder that. :) RegEx From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:02:25 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:02:15 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:20510 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:02:04 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 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 LAA07421 for ; Mon, 22 Jan 2001 11:01:53 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA62499; Mon, 22 Jan 2001 11:00:10 -0800 (PST) Date: Mon, 22 Jan 2001 10:58:22 -0800 (PST) From: Tom Duffy To: Russell Cattelan cc: Subject: Re: cmd/etherboot cmd/mknbi-linux cmd/lockstat ??? In-Reply-To: <3A6BA271.F2031E48@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing these directories are no longer built and would be ok to delete. we should ask hawkes if lockstat should go, but etherboot and mknbi-linux can be dumped as far as i am concerned. -tduffy On Sun, 21 Jan 2001, Russell Cattelan wrote: > > These directories have been tagging along in our tree since the > beginning. > > Can any find a good reason to keep them around? > If not I propose we nuke them. > > > -- > Russell Cattelan > cattelan@thebarn.com > > > From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:05:05 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:04:46 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38418 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:04:38 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04336 for ; Mon, 22 Jan 2001 11:13:35 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA547673; Mon, 22 Jan 2001 13:03:14 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA98279; Mon, 22 Jan 2001 13:03:14 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MJ3gB13609; Mon, 22 Jan 2001 13:03:42 -0600 Message-Id: <200101221903.f0MJ3gB13609@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jason Walker cc: Mark Hounschell , Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs In-Reply-To: Message from Jason Walker of "Mon, 22 Jan 2001 13:54:17 EST." Date: Mon, 22 Jan 2001 13:03:42 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Mon, 22 Jan 2001, Mark Hounschell wrote: > > > While I'm here does anyone know anything about the 2 problems I > > descibed above. > > > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > > 2. On an XFS fs, doing an ls in a directory that has a file larger then > > 2+gb gives a message about to large to stat. > > If I remember correctly, on linux x86, i.e. 32-bit linux, the VFS layer > is still 32 bit. this means that no matter XFS's or reisers limits, you are > limited to 2gb for files. Redhat has released a fix to increase that limit > to 4 or 8gb, I *think* in their "professional" kernels or whatever. I also > believe that SGI's development team is working with kernel developers for a > workaround so we can have a 64-bit VFS layer, thus truely being able to > exploit XFS's (and other fs's) ability. I have heard from friends (very > smart friends with nice boxes) that even old ext2's limit is not 2gb, that > it's a VFS thing. they claim that on a 64-bit arch. they can exceed the 2gb > file size limit no problem. Ponder that. :) Not quite true, the vfs allows file sizes much larger than this, file offset calculations and size fields are 64 bit. There are some limitations in other areas such as a device size limitation of 2 Tbytes - which should not be a practical problem for most people. Steve > > RegEx > From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:09:05 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:08:56 -0800 Received: from edge.coltex.nl ([194.151.97.115]:53520 "EHLO mail.coltex.nl") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:08:50 -0800 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id f0MJ8mZ29827 for ; Mon, 22 Jan 2001 20:08:48 +0100 Message-Id: <4.3.2.7.2.20010122195443.0410d670@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jan 2001 20:06:33 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: XFS starvation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, [seth@lsautom large]$ dd if=/dev/zero of=largefile.bin bs=1024 count=3500000 3500000+0 records in 3500000+0 records out [seth@lsautom large]$ Kills the machine for the next 3 minutes. The system is not usable during this time. I had a top open at the time I made the file and it jumped 3 minutes as soon as it was done. The CVS tree is of 16-01-01. It's running 2.4.0 on RedHat 7 with updates. The fs is on a IDE disk in a P3 450 with 128MB ram. There was work on a starvation fix, anybody on the status? Going to update the tree now. Bye -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:14:15 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:14:05 -0800 Received: from ns.caldera.de ([212.34.180.1]:30994 "EHLO ns.caldera.de") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:13:52 -0800 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id UAA26564; Mon, 22 Jan 2001 20:12:43 +0100 Date: Mon, 22 Jan 2001 20:12:43 +0100 From: Christoph Hellwig To: Jason Walker Cc: Mark Hounschell , Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs Message-ID: <20010122201243.A26507@caldera.de> References: <3A6C7E32.F5854394@compro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from unseen@sover.net on Mon, Jan 22, 2001 at 01:54:17PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 01:54:17PM -0500, Jason Walker wrote: > On Mon, 22 Jan 2001, Mark Hounschell wrote: > > > While I'm here does anyone know anything about the 2 problems I > > descibed above. > > > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > > 2. On an XFS fs, doing an ls in a directory that has a file larger then > > 2+gb gives a message about to large to stat. > > If I remember correctly, on linux x86, i.e. 32-bit linux, the VFS layer > is still 32 bit. this means that no matter XFS's or reisers limits, you are > limited to 2gb for files. Redhat has released a fix to increase that limit > to 4 or 8gb, I *think* in their "professional" kernels or whatever. I also > believe that SGI's development team is working with kernel developers for a > workaround so we can have a 64-bit VFS layer, thus truely being able to > exploit XFS's (and other fs's) ability. I have heard from friends (very > smart friends with nice boxes) that even old ext2's limit is not 2gb, that > it's a VFS thing. they claim that on a 64-bit arch. they can exceed the 2gb > file size limit no problem. Ponder that. :) Linux 2.4 has a '64bit VFS'. Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:27:05 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:26:46 -0800 Received: from Cantor.suse.de ([194.112.123.193]:5893 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 11:26:35 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 1A3901E1AF; Mon, 22 Jan 2001 20:26:33 +0100 (MET) Date: Mon, 22 Jan 2001 20:26:26 +0100 From: Andi Kleen To: Mark Hounschell Cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs Message-ID: <20010122202626.A12689@gruyere.muc.suse.de> References: <3A6C653C.B1983FE7@sgi.com> <3A6C7E32.F5854394@compro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6C7E32.F5854394@compro.net>; from markh@compro.net on Mon, Jan 22, 2001 at 01:38:43PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 01:38:43PM -0500, Mark Hounschell wrote: It's really offtopic, but I have to correct obviously wrong statements. > While I'm here does anyone know anything about the 2 problems I > descibed above. > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) The reiserfs 3.6 that got merged into 2.4 supports files >2GB when you let it convert the disk to a new disk format (this implies that 2.2 reiserfs cannot read it anymore) > 2. On an XFS fs, doing an ls in a directory that has a file larger then > 2+gb gives a message about to large to stat. You need to recompile your ls with _FILE_OFFSET_BITS=64 so that it uses stat64(). AFAIK recent gnu fileutils will do that automagically when you configure/compile them with LFS aware glibc headers. Generally programs cannot access files >2GB unless they were recompiled for LFS. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:30:46 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:30:36 -0800 Received: from Cantor.suse.de ([194.112.123.193]:24325 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 11:30:14 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 333BD1E1B2; Mon, 22 Jan 2001 20:30:11 +0100 (MET) Date: Mon, 22 Jan 2001 20:29:59 +0100 From: Andi Kleen To: Russell Cattelan Cc: Steve Lord , Scott Smyth , "'linux-xfs@oss.sgi.com '" Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) Message-ID: <20010122202959.B12689@gruyere.muc.suse.de> References: <200101221737.f0MHbDR12676@jen.americas.sgi.com> <3A6C81AD.2E66A128@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6C81AD.2E66A128@thebarn.com>; from cattelan@thebarn.com on Mon, Jan 22, 2001 at 12:53:33PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 12:53:33PM -0600, Russell Cattelan wrote: > Steve Lord wrote: > > > Also Note: all of XFS's meta data writes when using LVM or MD devices > should be in 512byte chunks. > The switching sizes messeages is a bit weird as no size should be > anything > but 512 (meta data) or 4096 (file data) Just a random side comment... nothing really important. This means that XFS won't work on Linux/s390 because it has devices that do not physically support 512 byte blocks. We had fun fixing LVM there which used to rely on 512byte writes too. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:40:35 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:40:16 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59672 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:40:10 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09197 for ; Mon, 22 Jan 2001 11:49:07 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA29257; Mon, 22 Jan 2001 13:38:54 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0MJbsd27311; Mon, 22 Jan 2001 13:37:54 -0600 Message-ID: <3A6C8C11.FB35C453@thebarn.com> Date: Mon, 22 Jan 2001 13:37:53 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Steve Lord , Scott Smyth , "'linux-xfs@oss.sgi.com '" Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) References: <200101221737.f0MHbDR12676@jen.americas.sgi.com> <3A6C81AD.2E66A128@thebarn.com> <20010122202959.B12689@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > On Mon, Jan 22, 2001 at 12:53:33PM -0600, Russell Cattelan wrote: > > Steve Lord wrote: > > > > > > Also Note: all of XFS's meta data writes when using LVM or MD devices > > should be in 512byte chunks. > > The switching sizes messeages is a bit weird as no size should be > > anything > > but 512 (meta data) or 4096 (file data) > > Just a random side comment... nothing really important. > > This means that XFS won't work on Linux/s390 because it has devices > that do not physically support 512 byte blocks. We had fun fixing LVM there > which used to rely on 512byte writes too. Ouch that one would be really hard to fix. This would require a bunch of XFS work. :-( > > > -Andi -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:43:06 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:42:46 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11289 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:42:42 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08937 for ; Mon, 22 Jan 2001 11:51:38 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA549968; Mon, 22 Jan 2001 13:41:21 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA00862; Mon, 22 Jan 2001 13:41:21 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MJfnK14537; Mon, 22 Jan 2001 13:41:49 -0600 Message-Id: <200101221941.f0MJfnK14537@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Russell Cattelan cc: Andi Kleen , Steve Lord , Scott Smyth , "'linux-xfs@oss.sgi.com '" Subject: Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+ (fwd) In-Reply-To: Message from Russell Cattelan of "Mon, 22 Jan 2001 13:37:53 CST." <3A6C8C11.FB35C453@thebarn.com> Date: Mon, 22 Jan 2001 13:41:49 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Andi Kleen wrote: > > > On Mon, Jan 22, 2001 at 12:53:33PM -0600, Russell Cattelan wrote: > > > Steve Lord wrote: > > > > > > > > > Also Note: all of XFS's meta data writes when using LVM or MD devices > > > should be in 512byte chunks. > > > The switching sizes messeages is a bit weird as no size should be > > > anything > > > but 512 (meta data) or 4096 (file data) > > > > Just a random side comment... nothing really important. > > > > This means that XFS won't work on Linux/s390 because it has devices > > that do not physically support 512 byte blocks. We had fun fixing LVM there > > which used to rely on 512byte writes too. > > Ouch that one would be really hard to fix. This would require a bunch of > XFS work. :-( There is always read/modify/write at the driver level - you just have to make it atomic. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:44:06 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:43:46 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13849 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:43:35 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08996 for ; Mon, 22 Jan 2001 11:52:32 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA45826; Mon, 22 Jan 2001 13:42:19 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0MJfJd27333; Mon, 22 Jan 2001 13:41:19 -0600 Message-ID: <3A6C8CDF.AE541383@thebarn.com> Date: Mon, 22 Jan 2001 13:41:19 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <200101221657.f0MGvjd11716@jen.americas.sgi.com> <3A6C6A4C.E71547C1@thebarn.com> <3A6C6E09.B7D1337D@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Florin Andrei wrote: > Russell Cattelan wrote: > > > > If your interested I could send you an XFS patch that can > > be applied to a 2.4.1pre8 tree. > > Yes, please send it to me. Ok ftp://oss.sgi.com/projects/xfs/download/2.4.1pre8.patch.gz Again THIS PATCH IS NOT TESTED. Use at your own risk. I'll try and get it installed shortly and run some quick tests. > > > -- > Florin Andrei > "Saying everything is a database is saying nothing at all > and certainly will not improve communication with others. > Database, database database. Database! See?" (Marc Lehmann) -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Mon Jan 22 11:56:25 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 11:56:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28698 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 11:55:52 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09667 for ; Mon, 22 Jan 2001 12:04:49 -0800 (PST) mail_from (hawkes@engr.sgi.com) Received: from pchawkes (sshgate.corp.sgi.com [169.238.216.146]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with SMTP id LAA79631; Mon, 22 Jan 2001 11:54:19 -0800 (PST) Message-ID: <022701c084ac$d11c2d60$6401a8c0@marin1.sfba.home.com> From: "John Hawkes" To: "Tom Duffy" , "Russell Cattelan" Cc: References: Subject: Re: cmd/etherboot cmd/mknbi-linux cmd/lockstat ??? Date: Mon, 22 Jan 2001 11:52:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing From: "Tom Duffy" > these directories are no longer built and would be ok to delete. we > should ask hawkes if lockstat should go I already replied to him. Yes, lockstat can go. I believe it's an artifact of the earlier ProPack inclusion of lockstat and lockmeter. John Hawkes From owner-linux-xfs@oss.sgi.com Mon Jan 22 12:02:26 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 12:02:06 -0800 Received: from [209.101.91.34] ([209.101.91.34]:12305 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 12:01:54 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id QAA21003; Mon, 22 Jan 2001 16:15:16 -0500 Message-ID: <3A6C935A.1F42640E@compro.net> Date: Mon, 22 Jan 2001 15:08:58 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <3A6C653C.B1983FE7@sgi.com> <3A6C7E32.F5854394@compro.net> <20010122202626.A12689@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Andi Kleen wrote: > > On Mon, Jan 22, 2001 at 01:38:43PM -0500, Mark Hounschell wrote: > It's really offtopic, but I have to correct obviously wrong statements. > > > While I'm here does anyone know anything about the 2 problems I > > descibed above. > > > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > > The reiserfs 3.6 that got merged into 2.4 supports files >2GB when you > let it convert the disk to a new disk format (this implies that 2.2 > reiserfs cannot read it anymore) I realize reiser 3.(something) will be in 2.4.1 kernel. It's not in the 2.4.0 that I just got. The reiser patch I used was 3.6.25. It was the latest they had on thier site. What do you mean "convert the disk to a new format" I have been reading (reiser list archives) and my problem with reiser almost seems to be a gcc revision problem. The Doc/Changes in the src tree implies not to use 2.95.2 but to use 2.91.rr so I went back to that revision for kernel compile. My dist is SuSE 6.4 + updates. Maybe I should go back to 2.95.2 from SuSE? I've also read the XFS doesn't like 2.95.2 so maybe the answer to the original posters question, is that the two filesystems cannot coexsist at this time and function properly. I'll have to try 2.95.2 gcc when I get home and see if it matters. Back to "convert the disk to a new format", what do you mean. Maybe I just left out a step??? > > > 2. On an XFS fs, doing an ls in a directory that has a file larger then > > 2+gb gives a message about to large to stat. > > You need to recompile your ls with _FILE_OFFSET_BITS=64 so that it uses > stat64(). AFAIK recent gnu fileutils will do that automagically when you > configure/compile them with LFS aware glibc headers. > Generally programs cannot access files >2GB unless they were recompiled > for LFS. I comliled/installed the latest fileutils but I may have neglected to insure the correct glibc was installed first. I'll double check that one when I get home. It would appear from the rest of the posts on the subject most agree glibc is probably my problem here. > > -Andi -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Mon Jan 22 12:29:55 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 12:29:35 -0800 Received: from [209.101.91.34] ([209.101.91.34]:26897 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 12:29:23 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id QAA21129; Mon, 22 Jan 2001 16:43:33 -0500 Message-ID: <3A6C99FB.B4D872A@compro.net> Date: Mon, 22 Jan 2001 15:37:15 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <4.3.2.7.2.20010122194858.037abad8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Mos wrote: > > At 13:38 22-1-2001 -0500, you wrote: > >Florin Andrei wrote: > > > > > > Is it possible right now to have both XFS and ReiserFS in the > > kernel? > > > (and maybe use them simultaneously, on different partitions) > > > > > > -- > > > Florin Andrei > > > "Saying everything is a database is saying nothing at all > > > and certainly will not improve communication with others. > > > Database, database database. Database! See?" (Marc Lehmann) > > > >Just yesterday I got it working. You must apply the reiser patch first > >then the XFS patch. I now have a 17g resier and a 17g xfs partition on > >my > >system coexsisting. I just finished last night and haven't really tested > >it much. 2 problems that I am having are, first the 2gb LFS isn't > >working > >with the reiser but does work with the XFS. The second problem is > >with the xfs. It may show up with the reiser also once I figure out the > >2gb file size problem. When I do an ls, any file that is larger the 2gb > >gives some message about something too large to stat. The file is there > >and I can actually read it. (JUST a large tar ball). You want to start > >with the vanilla 2.4.0 sources and what ever updates it requires. (See > >Doc/Changes), apply the reiser first the the xfs patches. > > While I'm here does anyone know anything about the 2 problems I > >descibed above. > > > >1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > >2. On an XFS fs, doing an ls in a directory that has a file larger then > > 2+gb gives a message about to large to stat. > > I can't comment on reiserfs, I have not used that in a while. > What distribution are you using, and more specific. The glibc version. It's a SuSE dist 6.4. glibc is from SuSE's shlibs-2.1.3-154 package. Looks like it's below rev. Thanks... > > You will need a recent glibc for the LFS AFAIK. > > [seth@lsautom large]$ ll -h > total 2.9G > -rw-r--r-- 1 seth staff 2.9G Jan 22 19:48 largefile.bin > [seth@lsautom large]$ > > This is on a redhat 7 glibc 2.2 system > -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Mon Jan 22 12:52:56 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 12:52:36 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:57186 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 12:52:25 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08919 for ; Mon, 22 Jan 2001 12:51:40 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA549535; Mon, 22 Jan 2001 14:49:49 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA10370; Mon, 22 Jan 2001 14:49:49 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MKoGp15525; Mon, 22 Jan 2001 14:50:16 -0600 Message-Id: <200101222050.f0MKoGp15525@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: ASSERT trip in XFS In-Reply-To: Message from Steve Lord of "Mon, 22 Jan 2001 11:27:34 CST." <200101221727.f0MHRYv12660@jen.americas.sgi.com> Date: Mon, 22 Jan 2001 14:50:16 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > > > With T-o-T XFS, on IDE, no kio, SMP, no HIGHMEM, qa 042 fails in page_daemo > n: > > (related to recent "xfs_strategy" changes ?) > > > > (failed 2 out of 2 runs) > > I cannot make this test fail for me, but I did manage to hit this via > other means. I will dig into it, but yes the strategy change looks like > a candidate for causing this. More to follow.... > > Steve > Daniel, can you try this patch, I do not have a sure fire way of triggering this problem on my hardware. The problem appears to be related to locking differences between Irix and Linux (again), the strategy call in Irix is called with the buffer locked for the duration, which means no one can change the underlying extents. In the Linux case we have one page locked, and anything else in the system can truncate the file out underneath us - we end up allocating a new extent from scratch rather than turning a delalloc into a real extent, this causes the extent to trip. This patch stops strategy from allocating real disk blocks beyond the current end of file, it could be more sophisticated, but this is more a proof of concept fix than anything else. Steve =========================================================================== Index: linux/fs/xfs/linux/xfs_lrw.c =========================================================================== --- /usr/tmp/TmpDir.15502-0/linux/fs/xfs/linux/xfs_lrw.c_1.72 Mon Jan 22 14:45:20 2001 +++ linux/fs/xfs/linux/xfs_lrw.c Mon Jan 22 14:44:09 2001 @@ -794,14 +794,12 @@ return XFS_ERROR(EIO); if (flags & PBF_READ) { - ASSERT(ismrlocked(&ip->i_iolock, MR_ACCESS | MR_UPDATE) != 0); unlocked = 0; lockmode = xfs_ilock_map_shared(ip); error = xfs_iomap_read(&ip->i_iocore, offset, count, XFS_BMAPI_ENTIRE, pbmapp, npbmaps, NULL); xfs_iunlock_map_shared(ip, lockmode); } else { /* PBF_WRITE */ - ASSERT(ismrlocked(&ip->i_iolock, MR_ACCESS | MR_UPDATE) != 0); ASSERT(flags & PBF_WRITE); vp = BHV_TO_VNODE(bdp); xfs_ilock(ip, XFS_ILOCK_EXCL); @@ -966,12 +964,25 @@ XFS_EXTSIZE_WR); } + /* * Allocate the backing store for the file. */ XFS_BMAP_INIT(&(free_list), &(first_block)); nimaps = XFS_STRAT_WRITE_IMAPS; + + /* + * Ensure we don't go beyond eof - it is possible + * the extents changed since we did the read call, + * we dropped the ilock in the interim. + */ + + end_fsb = XFS_B_TO_FSB(mp, XFS_SIZE(mp, io)); + if ((map_start_fsb + count_fsb) > end_fsb) { + count_fsb = end_fsb - map_start_fsb; + } + error = XFS_BMAPI(mp, tp, io, map_start_fsb, count_fsb, XFS_BMAPI_WRITE, &first_block, 1, imap, &nimaps, &free_list); From owner-linux-xfs@oss.sgi.com Mon Jan 22 12:58:35 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 12:58:25 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:24693 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 12:58:06 -0800 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA10286 for ; Mon, 22 Jan 2001 12:57:08 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f0MKvrG30115 for linux-xfs@oss.sgi.com; Mon, 22 Jan 2001 12:57:53 -0800 Date: Mon, 22 Jan 2001 12:57:53 -0800 From: Ananth Ananthanarayanan Message-Id: <200101222057.f0MKvrG30115@waco.engr.sgi.com> Subject: TAKE - cleanup cpages To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jan 22 12:56:40 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-delalloc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82680a linux/fs/pagebuf/page_buf_io.c - 1.43 - Cleanup usage of cpages for clustering. From owner-linux-xfs@oss.sgi.com Mon Jan 22 13:46:56 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 13:46:37 -0800 Received: from Cantor.suse.de ([194.112.123.193]:18962 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 13:46:30 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 4D92A1E1E9; Mon, 22 Jan 2001 22:46:28 +0100 (MET) Date: Mon, 22 Jan 2001 22:46:17 +0100 From: Andi Kleen To: Mark Hounschell Cc: Andi Kleen , Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs Message-ID: <20010122224617.A14047@gruyere.muc.suse.de> References: <3A6C653C.B1983FE7@sgi.com> <3A6C7E32.F5854394@compro.net> <20010122202626.A12689@gruyere.muc.suse.de> <3A6C935A.1F42640E@compro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6C935A.1F42640E@compro.net>; from markh@compro.net on Mon, Jan 22, 2001 at 03:08:58PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 03:08:58PM -0500, Mark Hounschell wrote: > Andi Kleen wrote: > > > > On Mon, Jan 22, 2001 at 01:38:43PM -0500, Mark Hounschell wrote: > > It's really offtopic, but I have to correct obviously wrong statements. > > > > > While I'm here does anyone know anything about the 2 problems I > > > descibed above. > > > > > > 1. No LFS support in reiser ( I know this ain't a reiser list. Sorry) > > > > The reiserfs 3.6 that got merged into 2.4 supports files >2GB when you > > let it convert the disk to a new disk format (this implies that 2.2 > > reiserfs cannot read it anymore) > > I realize reiser 3.(something) will be in 2.4.1 kernel. It's not in the > 2.4.0 that I just got. The reiser patch I used was 3.6.25. It > was the latest they had on thier site. What do you mean "convert the > disk > to a new format" I have been reading (reiser list archives) and my > problem > with reiser almost seems to be a gcc revision problem. The Doc/Changes There are no known reiserfs/gcc bugs (at least not known to me) > in > the src tree implies not to use 2.95.2 but to use 2.91.rr so I went back > to that revision for kernel compile. My dist is SuSE 6.4 + updates. > Maybe > I should go back to 2.95.2 from SuSE? I've also read the XFS doesn't > like > 2.95.2 so maybe the answer to the original posters question, is that the 2.95.SuSE-7.0/6.4 doesn't generate a working XFS for me. > two filesystems cannot coexsist at this time and function properly. I'll > have to try 2.95.2 gcc when I get home and see if it matters. Back to > "convert the disk to a new format", what do you mean. Maybe I just left > out a step??? When the disk was created using reiser 3.5 on 2.2. The 3.6 reiserfs will read/write it, but not support files >2GB. When you mount it with the "conv" option it'll convert the disk to 3.6 format and support big files, but you cannot go back to 2.2 anymore. I see no reason why reiserfs and xfs shouldn't work in the same kernel, except that it may OOM a bit faster because lots of memory can be pinned by both. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 13:54:37 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 13:54:27 -0800 Received: from Cantor.suse.de ([194.112.123.193]:48914 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 13:54:18 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 6D9A51E1E8; Mon, 22 Jan 2001 22:54:16 +0100 (MET) Date: Mon, 22 Jan 2001 22:54:10 +0100 From: Andi Kleen To: Steve Lord Cc: Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: ASSERT trip in XFS Message-ID: <20010122225410.A14193@gruyere.muc.suse.de> References: <200101222050.f0MKoGp15525@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: <200101222050.f0MKoGp15525@jen.americas.sgi.com>; from lord@sgi.com on Mon, Jan 22, 2001 at 02:50:16PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 02:50:16PM -0600, Steve Lord wrote: > Daniel, can you try this patch, I do not have a sure fire way of > triggering this problem on my hardware. The problem appears to be > related to locking differences between Irix and Linux (again), the > strategy call in Irix is called with the buffer locked for the > duration, which means no one can change the underlying extents. > In the Linux case we have one page locked, and anything else in > the system can truncate the file out underneath us - we end up > allocating a new extent from scratch rather than turning a delalloc > into a real extent, this causes the extent to trip. If you can get the linux inode semaphore it'll stop the truncates. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:09:28 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:09:18 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4398 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 14:09:04 -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 OAA07027 for ; Mon, 22 Jan 2001 14:18:00 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA550967; Mon, 22 Jan 2001 16:07:38 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA25287; Mon, 22 Jan 2001 16:07:38 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MM85M18074; Mon, 22 Jan 2001 16:08:05 -0600 Message-Id: <200101222208.f0MM85M18074@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: Steve Lord , Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: ASSERT trip in XFS In-Reply-To: Message from Andi Kleen of "Mon, 22 Jan 2001 22:54:10 +0100." <20010122225410.A14193@gruyere.muc.suse.de> Date: Mon, 22 Jan 2001 16:08:05 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Mon, Jan 22, 2001 at 02:50:16PM -0600, Steve Lord wrote: > > Daniel, can you try this patch, I do not have a sure fire way of > > triggering this problem on my hardware. The problem appears to be > > related to locking differences between Irix and Linux (again), the > > strategy call in Irix is called with the buffer locked for the > > duration, which means no one can change the underlying extents. > > In the Linux case we have one page locked, and anything else in > > the system can truncate the file out underneath us - we end up > > allocating a new extent from scratch rather than turning a delalloc > > into a real extent, this causes the extent to trip. > > If you can get the linux inode semaphore it'll stop the truncates. And deadlock when this code is callout out of a system call which already has the inode lock.... I think this one is nasty! Steve > > -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:15:17 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:14:58 -0800 Received: from Cantor.suse.de ([194.112.123.193]:46340 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 22 Jan 2001 14:14:38 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id DE1581E1ED; Mon, 22 Jan 2001 23:14:36 +0100 (MET) Date: Mon, 22 Jan 2001 23:14:30 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , Daniel Moore , linux-xfs@oss.sgi.com Subject: Re: ASSERT trip in XFS Message-ID: <20010122231430.A14441@gruyere.muc.suse.de> References: <200101222208.f0MM85M18074@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: <200101222208.f0MM85M18074@jen.americas.sgi.com>; from lord@sgi.com on Mon, Jan 22, 2001 at 04:08:05PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22, 2001 at 04:08:05PM -0600, Steve Lord wrote: > > On Mon, Jan 22, 2001 at 02:50:16PM -0600, Steve Lord wrote: > > > Daniel, can you try this patch, I do not have a sure fire way of > > > triggering this problem on my hardware. The problem appears to be > > > related to locking differences between Irix and Linux (again), the > > > strategy call in Irix is called with the buffer locked for the > > > duration, which means no one can change the underlying extents. > > > In the Linux case we have one page locked, and anything else in > > > the system can truncate the file out underneath us - we end up > > > allocating a new extent from scratch rather than turning a delalloc > > > into a real extent, this causes the extent to trip. > > > > If you can get the linux inode semaphore it'll stop the truncates. > > And deadlock when this code is callout out of a system call which already > has the inode lock.... > > I think this one is nasty! When the inode lock is already held there are no truncates to race. When it is not gotten by all calling paths I guess you can just change the callers to aquire it first. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:37:18 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:37:07 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:32551 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 14:36:50 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08708 for ; Mon, 22 Jan 2001 14:36:42 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA548235; Mon, 22 Jan 2001 16:35:19 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA27395; Mon, 22 Jan 2001 16:35:19 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0MMZke18991; Mon, 22 Jan 2001 16:35:46 -0600 Message-Id: <200101222235.f0MMZke18991@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Seth Mos cc: ananth@sgi.com (Rajagopal Ananthanarayanan), linux-xfs@oss.sgi.com Subject: Re: XFS starvation In-Reply-To: Message from Seth Mos of "Mon, 22 Jan 2001 20:06:33 +0100." <4.3.2.7.2.20010122195443.0410d670@pop.xs4all.nl> Date: Mon, 22 Jan 2001 16:35:46 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hi, > > [seth@lsautom large]$ dd if=/dev/zero of=largefile.bin bs=1024 count=3500000 > 3500000+0 records in > 3500000+0 records out > [seth@lsautom large]$ Yes, I have seen similar things - I have also recently found ways to deadlock the system via too much I/O going into XFS. Ananth may have some comments on dealing with starvation. Steve > > > Kills the machine for the next 3 minutes. > The system is not usable during this time. > I had a top open at the time I made the file and it jumped 3 minutes as > soon as it was done. > > The CVS tree is of 16-01-01. > > It's running 2.4.0 on RedHat 7 with updates. > The fs is on a IDE disk in a P3 450 with 128MB ram. > > There was work on a starvation fix, anybody on the status? > Going to update the tree now. > > Bye > -- > Seth > Has anybody seen my lightbulb? > I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:41:57 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:41:48 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:15403 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 14:41:32 -0800 Received: from info.engr.sgi.com ([192.26.80.216]) 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 OAA06321; Mon, 22 Jan 2001 14:41:30 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA39339; Mon, 22 Jan 2001 14:41:29 -0800 (PST) Date: Mon, 22 Jan 2001 14:41:29 -0800 (PST) Message-Id: <200101222241.OAA39339@info.engr.sgi.com> X-Pv-Incident: 813113 webPV: sgigate.sgi.com webExec: webpvsubmit,PvProjectIncident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@odin.corp.sgi.com (ananth@engr.sgi.com) Subject: BUG 813113 - kswapd issues To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=813113 Submitter : ananth Submitter Domain : engr Assigned Engineer : nb Assigned Domain : sgi.com Assigned Group : xfs-linux Category : software Customer Reported : T Priority : 2 Project : xfs-linux Status : open Description : Below is the state of a system that has kswapd (pid = 3) and a process performing I/O (pid = 1120) that are deadlocked waiting for each other. I'm sure that the wakeup_kswapd() changes in 2.4.1preX change this situation somewhat. However, in the long run, allocating memory under IOLOCK could still leave avenues for similar problems. Steve, we'll use this bug to record problems in this area. This instance is the fdatasync case, while running a 4-threaded doio on a 64MB machine (takes about an hour to hit it). If you find other backtraces, lets gather them here. Please feel free to assign the bug to yourself ;-) I'll provide an update w/ the 2.4.1pre patch applied. ananth. --------------------------------------------------------------- Entering kdb (current=0xc02bc000, pid 0) on processor 0 due to Keyboard Entry [0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc1160000 00000001 00000000 0 000 stop 0xc1160350 init 0xc1154000 00000002 00000001 0 000 stop 0xc1154350 keventd 0xc1146000 00000003 00000001 0 001 stop 0xc1146350 kswapd 0xc1144000 00000004 00000001 0 001 stop 0xc1144350 kreclaimd 0xc1140000 00000005 00000001 0 001 stop 0xc1140350 bdflush 0xc11fe000 00000006 00000001 0 001 stop 0xc11fe350 kupdate 0xc3e4c000 00000301 00000001 0 001 stop 0xc3e4c350 syslogd 0xc3544000 00000311 00000001 0 001 stop 0xc3544350 klogd 0xc34aa000 00000326 00000001 0 001 stop 0xc34aa350 portmap 0xc3456000 00000351 00000001 0 001 stop 0xc3456350 rpc.statd 0xc3c18000 00000369 00000001 0 000 stop 0xc3c18350 ypbind 0xc34e8000 00000371 00000369 0 001 stop 0xc34e8350 ypbind 0xc3374000 00000372 00000371 0 000 stop 0xc3374350 ypbind 0xc36ce000 00000373 00000371 0 001 stop 0xc36ce350 ypbind 0xc3410000 00000432 00000001 0 001 stop 0xc3410350 identd 0xc3c36000 00000434 00000432 0 000 stop 0xc3c36350 identd 0xc3d56000 00000435 00000434 0 000 stop 0xc3d56350 identd 0xc331e000 00000436 00000434 0 001 stop 0xc331e350 identd 0xc3336000 00000437 00000434 0 000 stop 0xc3336350 identd 0xc330c000 00000451 00000001 0 001 stop 0xc330c350 atd 0xc32ce000 00000482 00000001 0 000 stop 0xc32ce350 inetd [0]more> 0xc31ac000 00000518 00000001 0 000 stop 0xc31ac350 lpd 0xc3040000 00000538 00000001 0 001 stop 0xc3040350 amd 0xc3062000 00000541 00000001 0 001 stop 0xc3062350 rpciod 0xc3002000 00000542 00000001 0 000 stop 0xc3002350 lockd 0xc2dbc000 00000570 00000001 0 001 stop 0xc2dbc350 sendmail 0xc2f2a000 00000586 00000001 0 000 stop 0xc2f2a350 gpm 0xc2df6000 00000601 00000001 0 001 stop 0xc2df6350 crond 0xc2ef0000 00000632 00000001 0 001 stop 0xc2ef0350 rhnsd 0xc3eaa000 00000648 00000001 0 001 stop 0xc3eaa350 mingetty 0xc2eda000 00000649 00000001 0 001 stop 0xc2eda350 mingetty 0xc2dda000 00000650 00000001 0 000 stop 0xc2dda350 mingetty 0xc2ecc000 00000651 00000001 0 000 stop 0xc2ecc350 mingetty 0xc2c78000 00000652 00000001 0 000 stop 0xc2c78350 mingetty 0xc2dce000 00000653 00000001 0 001 stop 0xc2dce350 mingetty 0xc2e9a000 00000654 00000001 0 001 stop 0xc2e9a350 login 0xc2ef6000 00000655 00000001 0 001 stop 0xc2ef6350 getty 0xc2c40000 00000658 00000654 0 000 stop 0xc2c40350 bash 0xc0d2e000 00000682 00000001 0 000 stop 0xc0d2e350 pagebuf_daemon 0xc04fc000 00000683 00000001 0 001 stop 0xc04fc350 page_daemon 0xc3ef0000 00001115 00000658 0 000 stop 0xc3ef0350 bash 0xc232a000 00001116 00001115 0 000 stop 0xc232a350 iogen-l 0xc3930000 00001117 00001115 0 001 stop 0xc3930350 doio-l 0xc2898000 00001118 00001117 0 000 stop 0xc2898350 doio-l [0]more> 0xc268c000 00001119 00001117 0 001 stop 0xc268c350 doio-l 0xc1552000 00001120 00001117 0 000 stop 0xc1552350 doio-l 0xc2c3c000 00001121 00001117 0 000 stop 0xc2c3c350 doio-l 0xc04f6000 00001145 00000632 0 001 stop 0xc04f6350 rhn_check [0]kdb> btp 683 EBP EIP Function(args) 0xc04fdf78 0xc011284a schedule+0x41e (0xc04fdf8c) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc04fdfa0 0xc011237a schedule_timeout+0x7a (0xc101f538, 0x0) kernel .text 0xc0100000 0xc0112300 0xc011239c 0xc04fdfc4 0xc0112e4e interruptible_sleep_on_timeout+0x52 (0xf00, 0xc0d47cc0, 0xc0d47d78) kernel .text 0xc0100000 0xc0112dfc 0xc0112e78 0xc48650f0 [pagebuf]page_cleaner_daemon+0x280 pagebuf .text 0xc485f060 0xc4864e70 0xc4865138 0xc010750f kernel_thread+0x23 kernel .text 0xc0100000 0xc01074ec 0xc010751c [0]kdb> md pb_delalloc_pages 1 0xc48678d8 00000000 00000200 00000401 00000001 ................ [0]kdb> btp 3 EBP EIP Function(args) 0xc1147eb0 0xc011284a schedule+0x41e kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc486cb0e [xfs_support]lock_wait+0xa6 (0xc046ec48, 0xc046ec54, 0x1) xfs_support .text 0xc486c060 0xc486ca68 0xc486cb3c 0xc486cbed [xfs_support]mrupdatef_Rsmp_7860bc50+0x29 (0xc046ec30, 0x288) xfs_support .text 0xc486c060 0xc486cbc4 0xc486cc08 0xc48ab260 [xfs]xfs_ilock_ra+0x34 (0xc046eb7c, 0x1) xfs .text 0xc4872060 0xc48ab22c 0xc48ab2c0 0xc48ab2d3 [xfs]xfs_ilock+0x13 (0xc48c9808, 0xc046eb7c, 0x1) xfs .text 0xc4872060 0xc48ab2c0 0xc48ab2d8 0xc48c9808 [xfs]xfs_rwlock+0x4c (0xc046eb94, 0x2) xfs .text 0xc4872060 0xc48c97bc 0xc48c9814 0xc48cf1ad [xfs]linvfs_write_full_page+0x85 (0xc1070e80) xfs .text 0xc4872060 0xc48cf128 0xc48cf224 0xc0124a76 filemap_fdatasync+0x86 (0xc12ddc24, 0x10f00) kernel .text 0xc0100000 0xc01249f0 0xc0124af8 0xc01492b2 sync_all_inodes+0xfa kernel .text 0xc0100000 0xc01491b8 0xc0149334 0xc1147fa4 0xc0149785 prune_icache+0x31 (0x0) kernel .text 0xc0100000 0xc0149754 0xc0149864 0xc0149885 shrink_icache_memory+0x21 (0x6, 0x4, 0x6, 0x4) [0]more> kernel .text 0xc0100000 0xc0149864 0xc0149894 0xc012d5b3 do_try_to_free_pages+0x5b (0x4, 0x1, 0xc1161fb4) kernel .text 0xc0100000 0xc012d558 0xc012d5d8 0xc012d666 kswapd+0x8e kernel .text 0xc0100000 0xc012d5d8 0xc012d710 0xc010750f kernel_thread+0x23 kernel .text 0xc0100000 0xc01074ec 0xc010751c [0]kdb> btp 4 EBP EIP Function(args) 0xc1145fac 0xc011284a schedule+0x41e (0xc02aa460) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc1145fcc 0xc0112dd9 interruptible_sleep_on+0x4d (0x10f00, 0xc1161fa8) kernel .text 0xc0100000 0xc0112d8c 0xc0112dfc 0xc012d86f kreclaimd+0x5b kernel .text 0xc0100000 0xc012d814 0xc012d8f0 0xc010750f kernel_thread+0x23 kernel .text 0xc0100000 0xc01074ec 0xc010751c [0]kdb> btp 5 EBP EIP Function(args) 0xc1141fd8 0xc011284a schedule+0x41e (0x10f00) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc0138551 bdflush+0xd1 kernel .text 0xc0100000 0xc0138480 0xc013855c 0xc010750f kernel_thread+0x23 kernel .text 0xc0100000 0xc01074ec 0xc010751c [0]kdb> btp 6 EBP EIP Function(args) 0xc11ffd74 0xc011284a schedule+0x41e kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc012d7cb wakeup_kswapd+0xbb (0x1) kernel .text 0xc0100000 0xc012d710 0xc012d7e8 0xc012e4fe __alloc_pages+0x256 kernel .text 0xc0100000 0xc012e2a8 0xc012e5b0 0xc485fdf3 [pagebuf]_pagebuf_lookup_pages+0x327 (0xc21f7260, 0x8000, 0x0, 0x2000, 0x202201) pagebuf .text 0xc485f060 0xc485facc 0xc4860068 0xc4860231 [pagebuf]pagebuf_get_Rsmp_de233e60+0x171 (0xc3e68660, 0x8000, 0x0, 0x2000, 0x2201) pagebuf .text 0xc485f060 0xc48600c0 0xc48602ec 0xc48c0426 [xfs]xfs_trans_read_buf+0x5e (0xc3500000, 0x0, 0xc3500164, 0x40, 0x0) xfs .text 0xc4872060 0xc48c03c8 0xc48c0704 0xc48ab872 [xfs]xfs_itobp+0x11e (0xc3500000, 0x0, 0xc046eb7c, 0xc11fff78, 0xc11fff7c) xfs .text 0xc4872060 0xc48ab754 0xc48ab92c 0xc48c30ca [xfs]xfs_syncsub+0x542 (0xc3500000, 0x31, 0x0, 0x0) xfs .text 0xc4872060 0xc48c2b88 0xc48c3734 0xc48c2b81 [xfs]xfs_sync+0x15 (0xc3500000, 0x31, 0xc48dd5e0) xfs .text 0xc4872060 0xc48c2b6c 0xc48c2b88 0xc48d3878 [xfs]linvfs_write_super+0x28 (0xc2f20000) xfs .text 0xc4872060 0xc48d3850 0xc48d3884 0xc0139567 sync_supers+0x6f (0x0) [0]more> kernel .text 0xc0100000 0xc01394f8 0xc013959c 0xc0138356 sync_old_buffers+0x2a (0x10f00) kernel .text 0xc0100000 0xc013832c 0xc01383bc 0xc0138665 kupdate+0x109 kernel .text 0xc0100000 0xc013855c 0xc0138670 0xc010750f kernel_thread+0x23 kernel .text 0xc0100000 0xc01074ec 0xc010751c [0]kdb> btp 1117 EBP EIP Function(args) 0xc3931f7c 0xc011284a schedule+0x41e (0xc3930000) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc01185b6 sys_wait4+0x3c6 (0xffffffff, 0xbffffc5c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01181f0 0xc01185ec 0xc0108ff3 system_call+0x33 kernel .text 0xc0100000 0xc0108fc0 0xc0108ff8 [0]kdb> btp 1118 EBP EIP Function(args) 0xc2899e84 0xc011284a schedule+0x41e (0xc3b24e0c) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc0145b06 interruptible_sleep_on_locked+0x6a (0xc3b24e28, 0x0, 0xc3b247f0, 0xc3b24e0c) kernel .text 0xc0100000 0xc0145a9c 0xc0145b40 0xc0145b5c locks_block_on+0x1c (0xc3b247f0, 0xc3b24e0c) kernel .text 0xc0100000 0xc0145b40 0xc0145b6c 0xc014618e posix_lock_file+0xe2 (0xc2f26900, 0xc3b24e0c, 0x1) kernel .text 0xc0100000 0xc01460ac 0xc0146640 0xc014701d fcntl_setlk+0x12d (0x2, 0x7, 0xbffff5ec) kernel .text 0xc0100000 0xc0146ef0 0xc01470d0 0xc01430f1 do_fcntl+0x1c9 (0x2, 0x7, 0xbffff5ec, 0xc2f26900) kernel .text 0xc0100000 0xc0142f28 0xc0143214 0xc0143305 sys_fcntl64+0xb5 (0x2, 0x7, 0xbffff5ec, 0xbffffcdc, 0x2) kernel .text 0xc0100000 0xc0143250 0xc0143358 0xc0108ff3 system_call+0x33 kernel .text 0xc0100000 0xc0108fc0 0xc0108ff8 [0]kdb> btp 1119 EBP EIP Function(args) 0xc268deb0 0xc011284a schedule+0x41e (0x21da) kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc268dec8 0xc0107a54 __down+0x6c kernel .text 0xc0100000 0xc01079e8 0xc0107ab0 0xc0107bf8 __down_failed+0x8 (0x21da, 0xc268df6c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0107bf0 0xc0107bfc 0xc48d4b87 [xfs].text.lock+0x4cd xfs .text.lock 0xc48d46ba 0xc48d46ba 0xc48d4cd2 0xc48cc809 [xfs]linvfs_write+0x45 (0xc3dc8a20, 0x4c49c00a, 0x21da, 0xc3dc8a40, 0xc3dc8a20) xfs .text 0xc4872060 0xc48cc7c4 0xc48cc8dc 0xc0133ea6 do_readv_writev+0x1d6 (0x0, 0xc3dc8a20, 0xbffff450, 0x1) kernel .text 0xc0100000 0xc0133cd0 0xc0133f24 0xc0133fb9 sys_writev+0x41 (0x3, 0xbffff450, 0x1, 0x1, 0x3) kernel .text 0xc0100000 0xc0133f78 0xc0133fcc 0xc0108ff3 system_call+0x33 kernel .text 0xc0100000 0xc0108fc0 0xc0108ff8 [0]kdb> btp 1120 EBP EIP Function(args) 0xc1553d34 0xc011284a schedule+0x41e kernel .text 0xc0100000 0xc011242c 0xc0112a60 0xc012d7cb wakeup_kswapd+0xbb (0x1) kernel .text 0xc0100000 0xc012d710 0xc012d7e8 0xc012e4fe __alloc_pages+0x256 kernel .text 0xc0100000 0xc012e2a8 0xc012e5b0 0xc01278fe grab_cache_page+0x66 (0xc12ddc24, 0x358) kernel .text 0xc0100000 0xc0127898 0xc012793c 0xc4863e8b [pagebuf]__pagebuf_do_delwri+0x6f (0xc12ddb80, 0x358000, 0x0, 0x8000, 0x4c4b0993) pagebuf .text 0xc485f060 0xc4863e1c 0xc4864150 0xc486429a [pagebuf]_pagebuf_file_write+0x14a (0xc1f19ce0, 0x4c4b0993, 0x788c, 0xc1553ec0, 0x2) pagebuf .text 0xc485f060 0xc4864150 0xc48642d8 0xc48644db [pagebuf]pagebuf_generic_file_write_Rsmp_fba104b7+0x203 (0xc1f19ce0, 0x4c4b0993, 0x788c, 0xc1553f88, 0xc046eb7c) pagebuf .text 0xc485f060 0xc48642d8 0xc48647b4 0xc48d0203 [xfs]xfs_write+0x197 (0xc046eb94, 0xc1553f7c, 0x0, 0x0, 0x0) xfs .text 0xc4872060 0xc48d006c 0xc48d02c0 0xc48cc8b1 [xfs]linvfs_write+0xed (0xc1f19ce0, 0x4c49c008, 0x1c217, 0xc1f19d00) xfs .text 0xc4872060 0xc48cc7c4 0xc48cc8dc 0xc0133c9a sys_write+0x8e (0x4, 0x4c49c008, 0x1c217, 0xbffff8e8, 0x0) kernel .text 0xc0100000 0xc0133c0c 0xc0133cd0 0xc0108ff3 system_call+0x33 [0]more> kernel .text 0xc0100000 0xc0108fc0 0xc0108ff8 ------------------------------ From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:48:47 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:48:28 -0800 Received: from pike.sover.net ([209.198.87.34]:23516 "EHLO pike.sover.net") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 14:48:19 -0800 Received: from [192.168.1.3] (pm1a20.stj.sover.net [209.198.94.20]) by pike.sover.net (8.9.3/8.9.3) with ESMTP id RAA23215; Mon, 22 Jan 2001 17:48:06 -0500 (EST) Comments: SoVerNet Verification (on pike.sover.net) [192.168.1.3] from pm1a20.stj.sover.net [209.198.94.20] 209.198.94.20 Mon, 22 Jan 2001 17:48:06 -0500 (EST) Date: Mon, 22 Jan 2001 17:46:09 -0500 (EST) From: Jason Walker X-Sender: unseen@surreal.localdomain To: Steve Lord cc: Mark Hounschell , Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs In-Reply-To: <200101221903.f0MJ3gB13609@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 22 Jan 2001, Steve Lord wrote: > Not quite true, the vfs allows file sizes much larger than this, file offset > calculations and size fields are 64 bit. There are some limitations in other > areas such as a device size limitation of 2 Tbytes - which should not be a > practical problem for most people. ahh, ok then. it was to my understanding that VFS was 32 bit on 32 bit arch's. Thank you for clearing that up, I stand corrected. RegEx From owner-linux-xfs@oss.sgi.com Mon Jan 22 14:59:17 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 14:59:08 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14389 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 14:58:51 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03517 for ; Mon, 22 Jan 2001 15:07:48 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA61772 for ; Mon, 22 Jan 2001 14:53:45 -0800 (PST) Message-ID: <3A6CBAED.B08F80F6@sgi.com> Date: Mon, 22 Jan 2001 14:57:49 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS starvation References: <200101222235.f0MMZke18991@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > > > Hi, > > > > [seth@lsautom large]$ dd if=/dev/zero of=largefile.bin bs=1024 count=3500000 > > 3500000+0 records in > > 3500000+0 records out > > [seth@lsautom large]$ > > Yes, I have seen similar things - I have also recently found ways to deadlock > the system via too much I/O going into XFS. Ananth may have some comments on > dealing with starvation. I'm not sure whether it is the same as the deadlock issue, which btw, I just opened a bug against so we can track it. Seth Mos' problem seems to be recoverable, i.e. it is not a deadlock. I routinely run lmdd's where filesize = 4X memory size without problems. I just tried tried (on a 64MB box, my disk is smaller): dd if=/dev/zero of=/xfs/output bs=1024 count=1000000 and another window was running "top -d1" without any hesitation. I'm using the bleeding edge kernel. Let us know if you still see problems after updating your sources. thanks, ananth. > > > > > > Kills the machine for the next 3 minutes. > > The system is not usable during this time. > > I had a top open at the time I made the file and it jumped 3 minutes as > > soon as it was done. From owner-linux-xfs@oss.sgi.com Mon Jan 22 15:28:08 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 15:27:47 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:53255 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 15:27:29 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14KqMG-0003aR-00; Tue, 23 Jan 2001 00:26:44 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14KqMC-0002Dn-00; Tue, 23 Jan 2001 00:26:40 +0100 Date: Tue, 23 Jan 2001 00:26:40 +0100 From: Jens Axboe To: Rajagopal Ananthanarayanan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS starvation Message-ID: <20010123002640.A8459@suse.de> References: <200101222235.f0MMZke18991@jen.americas.sgi.com> <3A6CBAED.B08F80F6@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A6CBAED.B08F80F6@sgi.com>; from ananth@sgi.com on Mon, Jan 22, 2001 at 02:57:49PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 22 2001, Rajagopal Ananthanarayanan wrote: > > > [seth@lsautom large]$ dd if=/dev/zero of=largefile.bin bs=1024 count=3500000 > > > 3500000+0 records in > > > 3500000+0 records out > > > [seth@lsautom large]$ > > > > Yes, I have seen similar things - I have also recently found ways to deadlock > > the system via too much I/O going into XFS. Ananth may have some comments on > > dealing with starvation. > > I'm not sure whether it is the same as the deadlock issue, > which btw, I just opened a bug against so we can track it. > Seth Mos' problem seems to be recoverable, i.e. it is not > a deadlock. I routinely run lmdd's where filesize = 4X memory > size without problems. I just tried tried (on a 64MB box, > my disk is smaller): > > dd if=/dev/zero of=/xfs/output bs=1024 count=1000000 > > and another window was running "top -d1" without any hesitation. > I'm using the bleeding edge kernel. Let us know if you > still see problems after updating your sources. The max-locked-buffers heuristics should make this behave much better in the future, i.e. when XFS moves to 2.4.1. -- * Jens Axboe * SuSE Labs From owner-linux-xfs@oss.sgi.com Mon Jan 22 18:37:38 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 18:37:29 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:31604 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 18:37:08 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA11526; Mon, 22 Jan 2001 18:36:10 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA21569; Mon, 22 Jan 2001 18:37:07 -0800 (PST) Date: Mon, 22 Jan 2001 18:37:07 -0800 (PST) Message-Id: <200101230237.SAA21569@info.engr.sgi.com> X-Pv-Incident: 804570 webPV: getafix.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (chait@engr.sgi.com) Subject: ADD 804570 - The elevator bug To: nb@sgi.com Cc: raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com, eac@sgi.com, hasib@sgi.com, coreym@sgi.com, steiner@sgi.com, linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570 Status : open Priority : 3 Assigned Engineer : nb Submitter : coreym *Modified User : chait *Modified User Domain : engr *Description : I ran rwtest on a xfs-linux filesystem on the machine permit: rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 & This caused df, ls -l, fdisk, and top all to hang. Permit is running Redhat 6.2 with a 2.4.0-test5 kernel ========================== ADDITIONAL INFORMATION (ADD) ..... ========================== ADDITIONAL INFORMATION (ADD) From: chait@engr (BugWorks) Date: Jan 22 2001 06:37:06PM ========================== I just helped Ananth resolve some merging issues wrt. applying the 2.4.1pre9 patch to the XFS tree. Most of the conflicts were in the elevator.c file and ll_rw_blk.c file. So, I ended up doing a code review of Jen's fix for the elevator problem. His patch provides the following additional functionality: 1. consistent aging of requests, 2. request aging based on incoming buffer sizes, 3. eliminate redundant scans of the request queue for request insertion info. 1. and 2. primarily provide the fix we're looking for wrt. the elevator problem. Change number 3. is performance icing. Should be good to go for our SN/IA64 kernel. I'd wait for Ananth to post an update on his tests with the new kernel too. Cheers, -Chait. From owner-linux-xfs@oss.sgi.com Mon Jan 22 18:39:08 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 18:38:58 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:64884 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 18:38:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA11644 for ; Mon, 22 Jan 2001 18:37:46 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA33653 for linux-xfs@oss.sgi.com; Tue, 23 Jan 2001 13:37:22 +1100 (EST) Date: Tue, 23 Jan 2001 13:37:22 +1100 (EST) From: Nathan Scott Message-Id: <200101230237.NAA33653@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82716a Date: Mon Jan 22 18:37:23 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/quota/Makefile.in - 1.4 - fix some bugs in the logic of the install target. rework some things to make the patch cleaner, removing as many non-bugfix/ non-XFS changes as possible. cmd/quota/quotaon.8 - 1.4 - fix incorrect pathnames in the synopsis. From owner-linux-xfs@oss.sgi.com Mon Jan 22 22:14:38 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 22:14:19 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:31258 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 22:13:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA27108 for ; Mon, 22 Jan 2001 22:12:50 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA42041; Tue, 23 Jan 2001 17:12:25 +1100 (EST) Date: Tue, 23 Jan 2001 17:12:25 +1100 (EST) From: Nathan Scott Message-Id: <200101230612.RAA42041@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: tduffy@engr.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82730a Date: Mon Jan 22 22:10:08 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Makefile - 1.38 - add the patched quota rpms into the set we generate. cmd/quota/Makefile.in - 1.5 - minor cleanups in preparing the quota+xfs patch. cmd/quota/README.xfs - 1.4 - list the things we've changed in supporting xfs and fixing bugs. cmd/quota/configure.in - 1.4 cmd/quota/edquota.8 - 1.3 cmd/quota/edquota.c - 1.4 cmd/quota/hasquota.c - 1.5 cmd/quota/po/pl.mo - 1.2 cmd/quota/quota.1 - 1.4 cmd/quota/quota.c - 1.5 cmd/quota/quotacheck.8 - 1.3 cmd/quota/quotacheck.c - 1.4 cmd/quota/quotaio.c - 1.3 cmd/quota/quotaon.c - 1.7 cmd/quota/quotaops.c - 1.6 cmd/quota/quotaops.h - 1.3 cmd/quota/repquota.8 - 1.5 cmd/quota/repquota.c - 1.9 cmd/quota/rquotad.8 - 1.3 cmd/quota/setquota.8 - 1.5 cmd/quota/setquota.c - 1.6 - minor cleanups in preparing the quota+XFS patch. cmd/quota/warnquota.c - 1.4 - fix use of an uninitialized variable. SOURCES/quota-2.00-xfs.patch - 1.1 - patch for quota utilities which adds XFS support. SOURCES/quota-2.00.tar.gz - 1.1 - the version 2.00 quota tools, without XFS. SPECS/quota-xfs.spec - 1.1 - useful for generating quota rpms patched with XFS support. From owner-linux-xfs@oss.sgi.com Mon Jan 22 23:20:29 2001 Received: by oss.sgi.com id ; Mon, 22 Jan 2001 23:20:09 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:50752 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 Jan 2001 23:19:48 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA07738 for ; Mon, 22 Jan 2001 23:19:43 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA98008 for linux-xfs@oss.sgi.com; Tue, 23 Jan 2001 18:18:22 +1100 (EST) Date: Tue, 23 Jan 2001 18:18:22 +1100 (EST) From: Timothy Shimmin Message-Id: <200101230718.SAA98008@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACL config stuff Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing ACL config cleanup This takes out some #ifdef's of CONFIG_FS_POSIX_ACL for inline code and include's. I have left the #ifdefs of the struct fields and function definitions as this is consistent with some of the quota, dmapi and trace code. However, they could all be changed if one so desired. I took out a number of the xfs_iaccess() calls that were being $ifdef 0'ed out so as to avoid further confusion (in wrongly wanting to put them back in). Q: What is the story with xfs_stickytest() ? All calls are macro'ed out. The TAKE also puts the acl and attr sys calls into their own files instead of being in linux/fs/stat.c - this is like what Andreas' ACL patch does - it makes things clearer IMO. --Tim Modid: 2.4.x-xfs:slinx:82732a Date: Mon Jan 22 23:11:51 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs-acl Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/Makefile - 1.26 linux/fs/stat.c - 1.18 linux/fs/xfs/linux/xfs_iops.c - 1.91 linux/fs/xfs/xfs.h - 1.16 linux/fs/xfs/xfs_acl.h - 1.3 linux/fs/xfs/xfs_inode.c - 1.311 linux/fs/xfs/xfs_vnodeops.c - 1.487 linux/fs/ext_attr.c - 1.1 linux/fs/noposix_acl.c - 1.1 linux/fs/posix_acl.c - 1.1 From owner-linux-xfs@oss.sgi.com Tue Jan 23 02:29:49 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 02:29:30 -0800 Received: from bru5-smtp-out2.uunet.be ([194.7.1.6]:64425 "EHLO bru5-smtp-out2.uunet.be") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 02:28:59 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out2.uunet.be (8.11.2/8.11.2) with SMTP id f0NASpC01895; Tue, 23 Jan 2001 11:28:52 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id IAA02622; Tue, 23 Jan 2001 08:18:45 +0100 (MET) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA06791; Tue, 23 Jan 2001 09:07:13 +0100 Message-ID: <3A6D3BB1.8D47F52@vum.be> Date: Tue, 23 Jan 2001 09:07:13 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: troubles with xfs References: <200101221634.f0MGYc111617@jen.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing U3RldmUgTG9yZCB3cm90ZToNCg0KPiBnYXN0NkB2dW0uYmUgc2FpZDoNCj4gPj4gLi4uIGht bW0gc2VlbWVkIHRvIGJlIG9wdGltaXN0aWMuLi4NCj4gPj4gSSB0cmllZCB0byByZXBhaXIg dGhlIHJvb3Qgd2l0aCB4ZnMgcmVwYWlyIC4uLiB0aGF0IHdvcmtlZCAuLi4gYnV0IHRoZQ0K PiA+PiBzZWNvbmQgdGltZSAuLi4gaXQgbW92ZWQgc29tZSB0aGluZ3MgdG8gbG9zdCtmb3Vu ZCBub3cgSSBnZXQgYW4NCj4gPj4gdW5ib290YWJsZSBzeXN0ZW0uLi4NCj4gPj4NCj4gPj4g aXQgYm9vdHMgdXAgdW50aWwgICAgInR1cm5pbmcgb24gdXNlciBhbmQgZ3JvdXAgcXVvdGFz IGZvciBsb2NhbA0KPiA+PiBmaWxlc3lzdGVtcyAiIHRoZW4gSSBnZXQgICAgICIvZXRjL3Jj LnN5c2luaXQ6IHJtOmNvbW1hbmQgbm90IGZvdW5kIg0KPiA+Pg0KPiA+PiBJIGhhdmUgdG8g cmVpbnN0YWxsIC4uLiAgICAgICAgICAgICAgICAgOigNCj4gPj4NCj4gPj4gdGhpcyBpcyBv biBhIGxhcHRvcCB3aXRoIFhGUyBiZXRhNCBpc28gKFByZSBSZWxlYXNlIGl0IHNheXMgb24g dGhlIENEKQ0KPiA+Pg0KPg0KPiBDYW4geW91IGdpdmUgYSBtb3JlIGNvbXBsZXRlIGRlc2Ny aXB0aW9uIG9mIHdoYXQgeW91IGRpZD8gWW91IHNheSB5b3UNCj4gdHJpZWQgdG8gcmVwYWly IHRoZSByb290LCB3YXMgdGhpcyBmcm9tIHRoZSBtaW5pcm9vdD8NCj4NCj4gQWxzbywgYXMg YSBydWxlLCB4ZnNfcmVwYWlyIC1uIG9uIGEgcnVubmluZyBmaWxlc3lzdGVtIGNhbiBnaXZl IGNvbmZ1c2luZw0KPiBhbmQgaW52YWxpZCByZXN1bHRzLiBSZXBhaXIgaXMgcmVhZGluZyBk YXRhIGRpcmVjdCBmcm9tIHRoZSBkaXNrIGFuZCB3aWxsDQo+IG5vdCBzZWUgYW55dGhpbmcg c3RpbGwgaW4gYnVmZmVycyB3aXRoaW4gdGhlIGtlcm5lbCwgdGhpcyBjYW4gcmVzdWx0IGlu DQo+IGVycm9uZW91cyByZXBvcnRzIG9mIGNvcnJ1cHRpb24uIEFsc28gcnVubmluZyByZXBh aXIgb24gYSBmaWxlc3lzdGVtIHdoaWNoDQo+IHdhcyBub3QgY2xlYW5seSBzaHV0ZG93biBh bmQgaGFzIG5vdCBiZWVuIHJlbW91bnRlZCBzaW5jZSB0aGVuIGNhbiBhbHNvDQo+IHByb2R1 Y2Ugd29yc2UgcmVzdWx0cyB0aGFuIHJlbW91bnRpbmcgdGhlIGZpbGVzeXN0ZW0gdG8gcmVw bGF5IHRoZSBsb2csDQo+IHRoZW4gdW5tb3VudGluZyBhbmQgcnVubmluZyByZXBhaXIuDQo+ DQo+IEZpbmFsbHksIHJlcGFpciBwdXRzIHVubGlua2VkIGZpbGVzIGluIGEgbG9zdCtmb3Vu ZCBkaXJlY3RvcnksIGJ1dCBpZiBmaWxlcw0KPiBhcmUgbGVmdCB0aGVyZSBhbmQgcmVwYWly IGlzIHJ1biBhZ2FpbiwgaXQgd2lsbCB1bmxpbmsgbG9zdCtmb3VuZCBhbmQgZmluZA0KPiB0 aGUgZmlsZXMgYXMgdW5saW5rZWQgYWdhaW4uIFRoZSB0aGluZyB0byBkbyBpcyB0byBtb3Zl IHRoZSByZWNvdmVyZWQgZmlsZXMNCj4gc29tZXdoZXJlIGVsc2UgYmVmb3JlIHJ1bm5pbmcg cmVwYWlyIGFnYWluLg0KPg0KPiBTdGV2ZQ0KDQpJIG1hbmFnZWQgdG8gZG8gYSB4ZnNfcmVw YWlyIG9uIGl0ICB3aXRoIHRoZSBpbnN0YWxsIGNkIC4uLg0KDQphbmQgaGFkIGEgcnVubmlu ZyBzeXN0ZW0gYWdhaW4uDQoNCk9ubHkgb3RoZXIgcHJvYmxlbSBJIG5vdGljZWQgPSB0aGUg cGNtaWNpYSBwYWNrYWdlID0gZmF1bHR5IC4uLiBJIGNhbnQgZ2V0IG15DQpuZXR3b3JrIGNh cmQgdG8gd29yayAuLi4gd2lsbCBsb29rIGludG8gdGhhdCAuLi4NCih0aGUgc3RvY2sgcGNt Y2lhICwgY29taW5nIHdpdGggUkg3IGFpbnQgZ29vZCBhbHNvIC4uLiBpdCBoYXMgZmxhd3Mg Li4uIGxpa2UNCmluICB1bnN0YWJsZSB1bmRlciBoaWdoIGxvYWQgLi4uDQoNClNvIEkgbWFu YWdlZCB0byByZWN0aWZ5IHRoZSBzaXR1YXRpb24gYW5kIGNvdWxkIHJlYm9vdC4NCg0KSSBj aGVja2VkIHRoZSBtb3ZlZCBmaWxlJ3MgKGluIGxvc3QrZm91bmQpIGFuZCB0aGV5IHdlcmUg Ym90aCBkZXZpY2UgZmlsZXMgLi4uDQoNCnNvIEkgdGhpbmsgdGhlcmUncyBzb21ldGhpbmcg d2l0aCBkZXZmcyAuLi4uDQoNCg0KSSB3aWxsIHJldGVzdCBpbiBhIGZldw0KDQo= From owner-linux-xfs@oss.sgi.com Tue Jan 23 04:00:09 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 03:59:50 -0800 Received: from goldfinch.graham.com ([209.219.63.226]:28081 "EHLO graham.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 03:59:43 -0800 Received: (from ashok@localhost) by graham.com (8.9.3+Sun/8.9.1) id EAA25106 for linux-xfs@oss.sgi.com; Tue, 23 Jan 2001 04:00:45 -0800 (PST) From: Ashok Message-Id: <200101231200.EAA25106@graham.com> Subject: release version? To: linux-xfs@oss.sgi.com Date: Tue, 23 Jan 2001 04:00:45 -0800 (PST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I am looking at your XFS opensource page and notice that the date was Sept, 00. Has there been a release since then? Also, has there been any stability improvements since then? thanks, Ashok -- Ashok Yerneni 408-366-8001 x501 VP of Engineering, ashok@graham.com Graham Technology Solutions, http://www.graham.com 20823 Stevens Creek Blvd, #300 Cupertino, CA 95014. From owner-linux-xfs@oss.sgi.com Tue Jan 23 07:19:51 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 07:19:30 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:15717 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 07:19:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA06860 for ; Tue, 23 Jan 2001 07:18:10 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA556283; Tue, 23 Jan 2001 09:17:49 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA23407; Tue, 23 Jan 2001 09:17:49 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0NFI3020719; Tue, 23 Jan 2001 09:18:03 -0600 Message-Id: <200101231518.f0NFI3020719@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ashok cc: linux-xfs@oss.sgi.com Subject: Re: release version? In-Reply-To: Message from Ashok of "Tue, 23 Jan 2001 04:00:45 PST." <200101231200.EAA25106@graham.com> Date: Tue, 23 Jan 2001 09:18:03 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The web site is lagging reality again, the latest packaged version is here: ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9/ it is 2.4 based, the development version is available via cvs, there is not a huge difference right now, but the development version will keep diverging. Steve > Hi, > I am looking at your XFS opensource page and notice that > the date was Sept, 00. Has there been a release since then? > Also, has there been any stability improvements since then? > > thanks, > > Ashok > -- > Ashok Yerneni 408-366-8001 x501 > VP of Engineering, ashok@graham.com > Graham Technology Solutions, http://www.graham.com > 20823 Stevens Creek Blvd, #300 > Cupertino, CA 95014. From cattelan@thebarn.com Tue Jan 23 07:34:02 2001 Received: from lips.borg.umn.edu ([160.94.232.50]:36365 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 07:33:46 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0NFXiQ37808 for ; Tue, 23 Jan 2001 09:33:45 -0600 (CST) Sender: cattelan@thebarn.com Message-ID: <3A6DA453.22E860B8@thebarn.com> Date: Tue, 23 Jan 2001 09:33:39 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs-outgoing@oss.sgi.com Subject: [Fwd: FW: kernel 2.4+xfs oops] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing@oss.sgi.com Tony Gale wrote: > (third attempt at sending this message - mailing list doesn't > like me) > > Oops with backtraces enclosed. This is with a build using a > linux-2.4-xfs cvs co from Jan 4. > > Thanks > > -tony > > --- > E-Mail: Tony Gale > ... A booming voice says, "Wrong, cretin!", and you notice that you > have turned into a pile of dust. > > The views expressed above are entirely those of the writer > and do not represent the views, policy or understanding of > any other person or official body. > > ------------------------------------------------------------------------ > Name: trog2.txt > trog2.txt Type: Plain Text (text/plain) > Encoding: base64 > Download Status: Not downloaded with message -- Russell Cattelan cattelan@thebarn.com From cattelan@thebarn.com Tue Jan 23 11:21:41 2001 Received: from sgi.SGI.COM ([192.48.153.1]:1589 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 11:21:34 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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 LAA01047 for ; Tue, 23 Jan 2001 11:21:31 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA30960 for ; Tue, 23 Jan 2001 13:20:16 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0NJJG703098 for ; Tue, 23 Jan 2001 13:19:16 -0600 Sender: cattelan@sgi.com Message-ID: <3A6DD934.D8DA2A5B@thebarn.com> Date: Tue, 23 Jan 2001 13:19:16 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Trace dump from Tony Gale Content-Type: multipart/mixed; boundary="------------3E2A8AE8C9E625A1473E58D6" To: unlisted-recipients:; (no To-header on input) Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing@oss.sgi.com This is a multi-part message in MIME format. --------------3E2A8AE8C9E625A1473E58D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. --------------3E2A8AE8C9E625A1473E58D6 Content-Type: text/plain; charset=us-ascii; name="trog2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="trog2.txt" [1]kdb> bt EBP EIP Function(args) 0xda4b7cb4 0xc01c9076 mrupdatef+0xa (0x4, 0x0) kernel .text 0xc0100000 0xc01c906c 0xc01c90bc 0xda4b7cd4 0xc01be6bb xfs_reclaim+0x163 (0xe1008a94, 0x2) kernel .text 0xc0100000 0xc01be558 0xc01be710 0xda4b7ce8 0xc01c7e7d vn_reclaim+0x21 (0xef7ab944, 0x2) kernel .text 0xc0100000 0xc01c7e5c 0xc01c7eb0 0xda4b7d08 0xc01c83a8 vn_purge+0xac (0xef7ab944, 0xda4b7d1c) kernel .text 0xc0100000 0xc01c82fc 0xc01c83d0 0xda4b7d30 0xc01c84bf vn_remove+0x3b (0xef7ab944) kernel .text 0xc0100000 0xc01c8484 0xc01c84d0 0xda4b7d3c 0xc01c75d1 linvfs_clear_inode+0x1d (0xef7ab840) kernel .text 0xc0100000 0xc01c75b4 0xc01c75d8 0xda4b7d4c 0xc0148a7b clear_inode+0xb7 (0xef7ab840) kernel .text 0xc0100000 0xc01489c4 0xc0148aac 0xda4b7d60 0xc0149511 iput+0x15d (0xef7ab840) kernel .text 0xc0100000 0xc01493b4 0xc0149524 0xda4b7d6c 0xc01c8417 vn_rele+0xf (0xef7ab944) kernel .text 0xc0100000 0xc01c8408 0xc01c841c 0xda4b7db8 0xc01a005b xfs_iget_core+0x443 (0x0, 0xf7c67400, 0x0, 0x21c0f18a, 0x0) kernel .text 0xc0100000 0xc019fc18 0xc01a0268 0xda4b7df0 0xc01a0295 xfs_iget+0x2d (0xf7c67400, 0x0, 0x21c0f18a, 0x0, 0x0) [1]more> kernel .text 0xc0100000 0xc01a0268 0xc01a02a0 0xda4b7e60 0xc01b6353 xfs_dir_lookup_int+0x137 (0x0, 0xe08adab4, 0x5, 0xc3d656c0, 0xda4b7eec) kernel .text 0xc0100000 0xc01b621c 0xc01b64e0 0xda4b7ea8 0xc01ba9c2 xfs_lookup+0x8a (0xe08adab4, 0xc3d656c0, 0xda4b7ee8, 0xda4b7eec, 0x0) kernel .text 0xc0100000 0xc01ba938 0xc01baa2c 0xda4b7ef8 0xc01c2884 linvfs_lookup+0x70 (0xdc6925e0, 0xc3d65660) kernel .text 0xc0100000 0xc01c2814 0xc01c28d0 0xda4b7f1c 0xc013ebe8 real_lookup+0x84 (0xf23b2140, 0xda4b7f48, 0x0) kernel .text 0xc0100000 0xc013eb64 0xc013ec90 0xda4b7f54 0xc013f45f path_walk+0x64f (0xdc6a802d, 0xda4b7fa0) kernel .text 0xc0100000 0xc013ee10 0xc013f6d0 0xda4b7f70 0xc013fbb8 __user_walk+0x3c (0x86f7640, 0x9, 0xda4b7fa0) kernel .text 0xc0100000 0xc013fb7c 0xc013fbd8 0xda4b7fbc 0xc013271e sys_access+0x86 (0x86f7640, 0x4, 0xbffff0a4, 0xbffff036, 0xbffff006) kernel .text 0xc0100000 0xc0132698 0xc01327b4 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c [1]kdb> cpu 0 Entering kdb (current=0xe1f6c000, pid 27458) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc02757ce stext_lock+0x2236 kernel .text.lock 0xc0273598 0xc0273598 0xc0279900 0xe1f6df34 0xc013e9e1 permission+0x31 (0xd8d072a0, 0x1) kernel .text 0xc0100000 0xc013e9b0 0xc013ea48 0xe1f6df68 0xc013f6a8 path_walk+0x898 (0xdc022000, 0xe1f6dfa0) kernel .text 0xc0100000 0xc013ee10 0xc013f6d0 0xe1f6df84 0xc013fbb8 __user_walk+0x3c (0x809fdac, 0x8, 0xe1f6dfa0, 0xe1f6c000) kernel .text 0xc0100000 0xc013fb7c 0xc013fbd8 0xe1f6dfbc 0xc013bfd7 sys_newlstat+0x17 (0x809fdac, 0xbffffbd4, 0x48f75, 0x809fdb4, 0x809fdac) kernel .text 0xc0100000 0xc013bfc0 0xc013c030 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c [0]kdb> bta Stack traceback for pid 1 EBP EIP Function(args) 0xc1fffef0 0xc0114d42 schedule+0x416 (0xc1ffff04) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xc1ffff18 0xc011487a schedule_timeout+0x7a kernel .text 0xc0100000 0xc0114800 0xc011489c 0xc1ffff54 0xc014389f do_select+0x9f (0xb, 0xc1ffffa4, 0xc1ffffa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xc1ffffbc 0xc0143dda sys_select+0x3b6 (0xb, 0xbffff944, 0x0, 0x0, 0xbffff88c) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 2 EBP EIP Function(args) 0xc1ff1fa4 0xc0114d42 schedule+0x416 (0xf00, 0xc1ffffb0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xc1ff1fec 0xc0120dc5 context_thread+0x115 kernel .text 0xc0100000 0xc0120cb0 0xc0120e68 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 3 EBP EIP Function(args) 0xc1fe1f8c 0xc0114d42 schedule+0x416 (0xc1fe1fa0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xc1fe1fb4 0xc011487a schedule_timeout+0x7a (0x10f00, 0xc02874b1) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xc1fe1fd8 0xc011533e interruptible_sleep_on_timeout+0x52 (0xc1ffffa0, 0xc0105000) kernel .text 0xc0100000 0xc01152ec 0xc0115368 0xc1fe1fec 0xc012dac6 kswapd+0x10e kernel .text 0xc0100000 0xc012d9b8 0xc012dae8 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 4 EBP EIP Function(args) 0xf7ebffa8 0xc0114d42 schedule+0x416 (0xc03350a0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7ebffc8 0xc01152c9 interruptible_sleep_on+0x4d (0x10f00, 0xc1ffff94, 0xc0105000) kernel .text 0xc0100000 0xc011527c 0xc01152ec 0xf7ebffec 0xc012dc3a kreclaimd+0x5a kernel .text 0xc0100000 0xc012dbe0 0xc012dcd0 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 5 EBP EIP Function(args) 0xf7ebbfd8 0xc0114d42 schedule+0x416 (0x10f00) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7ebbfec 0xc0137d7e bdflush+0xfa kernel .text 0xc0100000 0xc0137c84 0xc0137d8c 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 6 EBP EIP Function(args) 0xf7eb9fac 0xc0114d42 schedule+0x416 (0xf7eb9fc0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7eb9fd4 0xc011487a schedule_timeout+0x7a (0x10f00) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7eb9fec 0xc0137e34 kupdate+0xa8 kernel .text 0xc0100000 0xc0137d8c 0xc0137eb0 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 75 EBP EIP Function(args) 0xf766bf8c 0xc0114d42 schedule+0x416 (0xf76d6200) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf766bfac 0xc01152c9 interruptible_sleep_on+0x4d (0xf766bfd8, 0xf766bfd8, 0xf00, 0xf767dc94, 0xf767dd68) kernel .text 0xc0100000 0xc011527c 0xc01152ec 0xf766bfec 0xc0168f63 pagebuf_daemon+0xd3 kernel .text 0xc0100000 0xc0168e90 0xc01690b8 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 76 EBP EIP Function(args) 0xf7669f74 0xc0114d42 schedule+0x416 (0xf7669f88) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7669f9c 0xc011487a schedule_timeout+0x7a (0xc17d3df8, 0x0) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7669fc0 0xc011533e interruptible_sleep_on_timeout+0x52 kernel .text 0xc0100000 0xc01152ec 0xc0115368 0xf7669fec 0xc016bec1 page_cleaner_daemon+0x2a1 kernel .text 0xc0100000 0xc016bc20 0xc016bf08 0xc0107503 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074e0 0xc0107518 Enter to end, to continue: Stack traceback for pid 306 EBP EIP Function(args) 0xf7443ef4 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7443f18 0xc0114817 schedule_timeout+0x17 kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7443f54 0xc014389f do_select+0x9f (0x1, 0xf7443fa4, 0xf7443fa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xf7443fbc 0xc0143dda sys_select+0x3b6 (0x1, 0xbffffd1c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 315 EBP EIP Function(args) 0xf740bf54 0xc0114d42 schedule+0x416 (0xffffffea) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf740bf84 0xc0117445 do_syslog+0xb5 (0x2, 0x804e760, 0xfff) kernel .text 0xc0100000 0xc0117390 0xc0117714 0xf740bf98 0xc0150b4a kmsg_read+0x12 (0xf7a19ce0, 0x804e760, 0xfff, 0xf7a19d00) kernel .text 0xc0100000 0xc0150b38 0xc0150b50 0xf740bfbc 0xc0133745 sys_read+0x91 (0x0, 0x804e760, 0xfff, 0x400, 0x804f760) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 329 EBP EIP Function(args) 0xf736ff68 0xc0114d42 schedule+0x416 (0xf736ff7c) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf736ff90 0xc011487a schedule_timeout+0x7a (0xf736e000, 0xbffffbf4, 0xbffffd08) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf736ffbc 0xc011d1a4 sys_nanosleep+0xf4 (0xbffffbf4, 0xbffffbf4, 0x4012d7fc, 0xbffffbf4, 0xbffffd08) kernel .text 0xc0100000 0xc011d0b0 0xc011d220 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 343 EBP EIP Function(args) 0xf7297ef4 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7297f18 0xc0114817 schedule_timeout+0x17 kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7297f54 0xc014389f do_select+0x9f (0x6, 0xf7297fa4, 0xf7297fa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xf7297fbc 0xc0143dda sys_select+0x3b6 (0x6, 0xbffffd14, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 402 EBP EIP Function(args) 0xf78b3ee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf78b3f04 0xc0114817 schedule_timeout+0x17 (0xf78b2000, 0xf7872000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf78b3f70 0xc01dedc5 read_chan+0x341 (0xf7872000, 0xf72b5f20, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf78b3f98 0xc01daded tty_read+0xe5 (0xf72b5f20, 0xbffffdfb, 0x1, 0xf72b5f40) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf78b3fbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 403 EBP EIP Function(args) 0xf729dee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf729df04 0xc0114817 schedule_timeout+0x17 (0xf729c000, 0xf7a1a000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf729df70 0xc01dedc5 read_chan+0x341 (0xf7a1a000, 0xf72b5f80, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf729df98 0xc01daded tty_read+0xe5 (0xf72b5f80, 0xbffffdfb, 0x1, 0xf72b5fa0) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf729dfbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 404 EBP EIP Function(args) 0xf7393ee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7393f04 0xc0114817 schedule_timeout+0x17 (0xf7392000, 0xf7052000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7393f70 0xc01dedc5 read_chan+0x341 (0xf7052000, 0xf7c55ba0, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf7393f98 0xc01daded tty_read+0xe5 (0xf7c55ba0, 0xbffffdfb, 0x1, 0xf7c55bc0) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf7393fbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 405 EBP EIP Function(args) 0xf73cfee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf73cff04 0xc0114817 schedule_timeout+0x17 (0xf73ce000, 0xf7278000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf73cff70 0xc01dedc5 read_chan+0x341 (0xf7278000, 0xf7a19e00, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf73cff98 0xc01daded tty_read+0xe5 (0xf7a19e00, 0xbffffdfb, 0x1, 0xf7a19e20) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf73cffbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 406 EBP EIP Function(args) 0xf7401ee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf7401f04 0xc0114817 schedule_timeout+0x17 (0xf7400000, 0xf70cb000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf7401f70 0xc01dedc5 read_chan+0x341 (0xf70cb000, 0xf7c55a20, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf7401f98 0xc01daded tty_read+0xe5 (0xf7c55a20, 0xbffffdfb, 0x1, 0xf7c55a40) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf7401fbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 407 EBP EIP Function(args) 0xf738fee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf738ff04 0xc0114817 schedule_timeout+0x17 (0xf738e000, 0xf717e000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf738ff70 0xc01dedc5 read_chan+0x341 (0xf717e000, 0xf7a19bc0, 0xbffffdfb, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf738ff98 0xc01daded tty_read+0xe5 (0xf7a19bc0, 0xbffffdfb, 0x1, 0xf7a19be0) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf738ffbc 0xc0133745 sys_read+0x91 (0x0, 0xbffffdfb, 0x1, 0xbffffdfb, 0x804b180) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 408 EBP EIP Function(args) 0xf728de2c 0xc0114d42 schedule+0x416 (0xf6f88000, 0xf7a196e0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf728de78 0xc01ef5f8 block_til_ready+0x25c (0xf6f88000, 0xf7a196e0, 0xf78feee0) kernel .text 0xc0100000 0xc01ef39c 0xc01ef644 0xf728dea0 0xc01ef8ac rs_open+0x10c (0xf6f88000, 0xf7a196e0) kernel .text 0xc0100000 0xc01ef7a0 0xc01ef958 0xf728df24 0xc01dbda0 tty_open+0x244 (0xf74a5be0, 0xf7a196e0, 0xf7a196e0) kernel .text 0xc0100000 0xc01dbb5c 0xc01dbf04 0xf728df40 0xc0133fd5 chrdev_open+0x69 (0xf74a5be0, 0xf7a196e0, 0xbffffe5c) kernel .text 0xc0100000 0xc0133f6c 0xc0134018 0xf728df5c 0xc0132f41 dentry_open+0xbd (0xf756bcc0, 0xf7c66ee0, 0x2) kernel .text 0xc0100000 0xc0132e84 0xc0132fdc 0xf728df98 0xc0132e77 filp_open+0x4f (0xf753b000, 0x2, 0xbffffe5c) kernel .text 0xc0100000 0xc0132e28 0xc0132e84 0xf728dfbc 0xc013317e sys_open+0x42 (0x8052e60, 0x2, 0xbffffe5c, 0x4, 0xbffffe5c) kernel .text 0xc0100000 0xc013313c 0xc013323c 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 28261 EBP EIP Function(args) 0xf6c97f7c 0xc0114d42 schedule+0x416 (0xf6c96000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf6c97fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbfffef6c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 28259 EBP EIP Function(args) 0xf6c95ef0 0xc0114d42 schedule+0x416 (0xf6c95f04) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf6c95f18 0xc011487a schedule_timeout+0x7a kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf6c95f54 0xc014389f do_select+0x9f (0x13, 0xf6c95fa4, 0xf6c95fa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xf6c95fbc 0xc0143dda sys_select+0x3b6 (0x13, 0xbffffc80, 0xbffffc00, 0x0, 0xbffffbf8) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 28283 EBP EIP Function(args) 0xf6c91f7c 0xc0114d42 schedule+0x416 (0xf6c90000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf6c91fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbfffe1c0, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 9127 EBP EIP Function(args) 0xd157bef4 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xd157bf18 0xc0114817 schedule_timeout+0x17 kernel .text 0xc0100000 0xc0114800 0xc011489c 0xd157bf54 0xc014389f do_select+0x9f (0x4, 0xd157bfa4, 0xd157bfa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xd157bfbc 0xc0143dda sys_select+0x3b6 (0x4, 0xbffffc24, 0xbffffba4, 0xbffffb24, 0x0) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 9128 EBP EIP Function(args) 0xe4ab7f7c 0xc0114d42 schedule+0x416 (0xe4ab6000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xe4ab7fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0x0, 0x0, 0x0, 0xbfffdf1c) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 9129 EBP EIP Function(args) 0xcb8d5f7c 0xc0114d42 schedule+0x416 (0xcb8d4000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xcb8d5fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbffffabc, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 9149 EBP EIP Function(args) 0xf6a03f7c 0xc0114d42 schedule+0x416 (0xf6a02000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf6a03fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbffff9d8, 0x2, 0x0, 0xbffffb38) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 9151 EBP EIP Function(args) 0xf6a01ee0 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf6a01f04 0xc0114817 schedule_timeout+0x17 (0xf6a00000, 0xdc9e4000) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf6a01f70 0xc01dedc5 read_chan+0x341 (0xdc9e4000, 0xf6c44aa0, 0xbffff157, 0x1) kernel .text 0xc0100000 0xc01dea84 0xc01df11c 0xf6a01f98 0xc01daded tty_read+0xe5 (0xf6c44aa0, 0xbffff157, 0x1, 0xf6c44ac0) kernel .text 0xc0100000 0xc01dad08 0xc01dae44 0xf6a01fbc 0xc0133745 sys_read+0x91 (0x0, 0xbffff157, 0x1, 0xbffff157, 0x1) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 6674 EBP EIP Function(args) 0xc87cdef0 0xc0114d42 schedule+0x416 (0xc87cdf04) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xc87cdf18 0xc011487a schedule_timeout+0x7a kernel .text 0xc0100000 0xc0114800 0xc011489c 0xc87cdf54 0xc014389f do_select+0x9f (0x1, 0xc87cdfa4, 0xc87cdfa0) kernel .text 0xc0100000 0xc0143800 0xc01439fc 0xc87cdfbc 0xc0143dda sys_select+0x3b6 (0x1, 0xbffffcf0, 0xbffffc70, 0xbffffbf0, 0xbffffae8) kernel .text 0xc0100000 0xc0143a24 0xc0143f10 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 6675 EBP EIP Function(args) 0xf0eabe5c 0xc0114d42 schedule+0x416 kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf0eabe80 0xc0114817 schedule_timeout+0x17 kernel .text 0xc0100000 0xc0114800 0xc011489c 0xf0eabec4 0xc02694ee unix_stream_data_wait+0x8a (0xe64cf9a0, 0x7fffffff) kernel .text 0xc0100000 0xc0269464 0xc0269568 0xf0eabf10 0xc026967d unix_stream_recvmsg+0x115 (0xd2860b04, 0xf0eabf7c, 0x10000, 0x0, 0xf0eabf40) kernel .text 0xc0100000 0xc0269568 0xc0269920 0xf0eabf54 0xc0231836 sock_recvmsg+0x36 (0xd2860b04, 0xf0eabf7c, 0x10000, 0x0) kernel .text 0xc0100000 0xc0231800 0xc02318ac 0xf0eabf98 0xc0231941 sock_read+0x81 (0xc6e0dce0, 0x401a6000, 0x10000, 0xc6e0dd00) kernel .text 0xc0100000 0xc02318c0 0xc023194c 0xf0eabfbc 0xc0133745 sys_read+0x91 (0x0, 0x401a6000, 0x10000, 0x4016be80, 0x4016be80) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 24694 EBP EIP Function(args) 0xf0551f38 0xc0114d42 schedule+0x416 (0xf72b53e0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xf0551f6c 0xc013db3f pipe_wait+0x6f (0xf146f040) kernel .text 0xc0100000 0xc013dad0 0xc013db6c 0xf0551f98 0xc013dc2b pipe_read+0xbf (0xf72b53e0, 0x40017000, 0x1000, 0xf72b5400) kernel .text 0xc0100000 0xc013db6c 0xc013dda8 0xf0551fbc 0xc0133745 sys_read+0x91 (0x5, 0x40017000, 0x1000, 0x80510e0, 0x80512bb) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 24695 EBP EIP Function(args) 0xd3e85f7c 0xc0114d42 schedule+0x416 (0xd3e84000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xd3e85fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbfffed38, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 27343 EBP EIP Function(args) 0xdc4c1f38 0xc0114d42 schedule+0x416 (0xf6a7ec60) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xdc4c1f6c 0xc013db3f pipe_wait+0x6f (0xf30027e0) kernel .text 0xc0100000 0xc013dad0 0xc013db6c 0xdc4c1f98 0xc013dc2b pipe_read+0xbf (0xf6a7ec60, 0x40017000, 0x1000, 0xf6a7ec80) kernel .text 0xc0100000 0xc013db6c 0xc013dda8 0xdc4c1fbc 0xc0133745 sys_read+0x91 (0x5, 0x40017000, 0x1000, 0x8051390, 0x8050569) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 27344 EBP EIP Function(args) 0xcdec3f7c 0xc0114d42 schedule+0x416 (0xcdec2000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xcdec3fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbffff604, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 27457 EBP EIP Function(args) 0xe3399f7c 0xc0114d42 schedule+0x416 (0xe3398000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xe3399fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbffffa9c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 27458 EBP EIP Function(args) 0xc02757ce stext_lock+0x2236 kernel .text.lock 0xc0273598 0xc0273598 0xc0279900 0xc013e9e1 permission+0x31 (0xd8d072a0, 0x1) kernel .text 0xc0100000 0xc013e9b0 0xc013ea48 0xe1f6df68 0xc013f6a8 path_walk+0x898 (0xdc022000, 0xe1f6dfa0) kernel .text 0xc0100000 0xc013ee10 0xc013f6d0 0xe1f6df84 0xc013fbb8 __user_walk+0x3c (0x809fdac, 0x8, 0xe1f6dfa0, 0xe1f6c000) kernel .text 0xc0100000 0xc013fb7c 0xc013fbd8 0xe1f6dfbc 0xc013bfd7 sys_newlstat+0x17 (0x809fdac, 0xbffffbd4, 0x48f75, 0x809fdb4, 0x809fdac) kernel .text 0xc0100000 0xc013bfc0 0xc013c030 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 1382 EBP EIP Function(args) 0xd3c91f7c 0xc0114d42 schedule+0x416 (0xd3c90000, 0x0) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xd3c91fbc 0xc0119063 sys_wait4+0x397 (0xffffffff, 0xbfffe80c, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0118ccc 0xc0119094 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 1383 EBP EIP Function(args) 0xe42cff38 0xc0114d42 schedule+0x416 (0xf6d04c60) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xe42cff6c 0xc013db3f pipe_wait+0x6f (0xf0a99640) kernel .text 0xc0100000 0xc013dad0 0xc013db6c 0xe42cff98 0xc013dc2b pipe_read+0xbf (0xf6d04c60, 0x8056150, 0x2000, 0xf6d04c80) kernel .text 0xc0100000 0xc013db6c 0xc013dda8 0xe42cffbc 0xc0133745 sys_read+0x91 (0x0, 0x8056150, 0x2000, 0x0, 0x4012be80) kernel .text 0xc0100000 0xc01336b4 0xc0133780 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 1384 EBP EIP Function(args) 0xe1008a7c 0xc01c9076 mrupdatef+0xa (0x4, 0x0) kernel .text 0xc0100000 0xc01c906c 0xc01c90bc 0xda4b7cd4 0xc01be6bb xfs_reclaim+0x163 (0xe1008a94, 0x2) kernel .text 0xc0100000 0xc01be558 0xc01be710 0xda4b7ce8 0xc01c7e7d vn_reclaim+0x21 (0xef7ab944, 0x2) kernel .text 0xc0100000 0xc01c7e5c 0xc01c7eb0 0xda4b7d08 0xc01c83a8 vn_purge+0xac (0xef7ab944, 0xda4b7d1c) kernel .text 0xc0100000 0xc01c82fc 0xc01c83d0 0xda4b7d30 0xc01c84bf vn_remove+0x3b (0xef7ab944) kernel .text 0xc0100000 0xc01c8484 0xc01c84d0 0xda4b7d3c 0xc01c75d1 linvfs_clear_inode+0x1d (0xef7ab840) kernel .text 0xc0100000 0xc01c75b4 0xc01c75d8 0xda4b7d4c 0xc0148a7b clear_inode+0xb7 (0xef7ab840) kernel .text 0xc0100000 0xc01489c4 0xc0148aac 0xda4b7d60 0xc0149511 iput+0x15d (0xef7ab840) kernel .text 0xc0100000 0xc01493b4 0xc0149524 0xda4b7d6c 0xc01c8417 vn_rele+0xf (0xef7ab944) kernel .text 0xc0100000 0xc01c8408 0xc01c841c 0xda4b7db8 0xc01a005b xfs_iget_core+0x443 (0x0, 0xf7c67400, 0x0, 0x21c0f18a, 0x0) kernel .text 0xc0100000 0xc019fc18 0xc01a0268 [0]more> 0xda4b7df0 0xc01a0295 xfs_iget+0x2d (0xf7c67400, 0x0, 0x21c0f18a, 0x0, 0x0) kernel .text 0xc0100000 0xc01a0268 0xc01a02a0 0xda4b7e60 0xc01b6353 xfs_dir_lookup_int+0x137 (0x0, 0xe08adab4, 0x5, 0xc3d656c0, 0xda4b7eec) kernel .text 0xc0100000 0xc01b621c 0xc01b64e0 0xda4b7ea8 0xc01ba9c2 xfs_lookup+0x8a (0xe08adab4, 0xc3d656c0, 0xda4b7ee8, 0xda4b7eec, 0x0) kernel .text 0xc0100000 0xc01ba938 0xc01baa2c 0xda4b7ef8 0xc01c2884 linvfs_lookup+0x70 (0xdc6925e0, 0xc3d65660) kernel .text 0xc0100000 0xc01c2814 0xc01c28d0 0xda4b7f1c 0xc013ebe8 real_lookup+0x84 (0xf23b2140, 0xda4b7f48, 0x0) kernel .text 0xc0100000 0xc013eb64 0xc013ec90 0xda4b7f54 0xc013f45f path_walk+0x64f (0xdc6a802d, 0xda4b7fa0) kernel .text 0xc0100000 0xc013ee10 0xc013f6d0 0xda4b7f70 0xc013fbb8 __user_walk+0x3c (0x86f7640, 0x9, 0xda4b7fa0) kernel .text 0xc0100000 0xc013fb7c 0xc013fbd8 0xda4b7fbc 0xc013271e sys_access+0x86 (0x86f7640, 0x4, 0xbffff0a4, 0xbffff036, 0xbffff006) kernel .text 0xc0100000 0xc0132698 0xc01327b4 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: Stack traceback for pid 1385 EBP EIP Function(args) 0xd02f9f68 0xc0114d42 schedule+0x416 (0xd02f9f7c) kernel .text 0xc0100000 0xc011492c 0xc0114f50 0xd02f9f90 0xc011487a schedule_timeout+0x7a (0xd02f8000, 0xbfffed74, 0xbfffee88) kernel .text 0xc0100000 0xc0114800 0xc011489c 0xd02f9fbc 0xc011d1a4 sys_nanosleep+0xf4 (0xbfffed74, 0xbfffed74, 0x4012d7fc, 0xbfffed74, 0xbfffee88) kernel .text 0xc0100000 0xc011d0b0 0xc011d220 0xc0109057 system_call+0x33 kernel .text 0xc0100000 0xc0109024 0xc010905c Enter to end, to continue: [0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc1ffe000 00000001 00000000 0 000 stop 0xc1ffe350 init 0xc1ff0000 00000002 00000001 0 000 stop 0xc1ff0350 keventd 0xc1fe0000 00000003 00000001 0 001 stop 0xc1fe0350 kswapd 0xf7ebe000 00000004 00000001 0 001 stop 0xf7ebe350 kreclaimd 0xf7eba000 00000005 00000001 0 000 stop 0xf7eba350 bdflush 0xf7eb8000 00000006 00000001 0 000 stop 0xf7eb8350 kupdate 0xf766a000 00000075 00000001 0 001 stop 0xf766a350 pagebuf_daemon 0xf7668000 00000076 00000001 0 000 stop 0xf7668350 page_daemon 0xf7442000 00000306 00000001 0 001 stop 0xf7442350 syslogd 0xf740a000 00000315 00000001 0 000 run 0xf740a350 klogd 0xf736e000 00000329 00000001 0 001 stop 0xf736e350 crond 0xf7296000 00000343 00000001 0 001 stop 0xf7296350 inetd 0xf78b2000 00000402 00000001 0 001 stop 0xf78b2350 mingetty 0xf729c000 00000403 00000001 0 000 stop 0xf729c350 mingetty 0xf7392000 00000404 00000001 0 001 stop 0xf7392350 mingetty 0xf73ce000 00000405 00000001 0 000 stop 0xf73ce350 mingetty 0xf7400000 00000406 00000001 0 001 stop 0xf7400350 mingetty 0xf738e000 00000407 00000001 0 001 stop 0xf738e350 mingetty 0xf728c000 00000408 00000001 0 001 stop 0xf728c350 getty 0xf6c96000 00028261 00000001 0 001 stop 0xf6c96350 rc.news 0xf6c94000 00028259 00000001 0 000 stop 0xf6c94350 innd [0]more> 0xf6c90000 00028283 00028261 0 001 stop 0xf6c90350 innwatch 0xd157a000 00009127 00000343 0 001 stop 0xd157a350 in.telnetd 0xe4ab6000 00009128 00009127 0 000 stop 0xe4ab6350 login 0xcb8d4000 00009129 00009128 0 001 stop 0xcb8d4350 bash 0xf6a02000 00009149 00009129 0 000 stop 0xf6a02350 su 0xf6a00000 00009151 00009149 0 000 stop 0xf6a00350 bash 0xc87cc000 00006674 00028259 0 001 stop 0xc87cc350 innfeed 0xf0eaa000 00006675 00028259 0 000 stop 0xf0eaa350 controlchan 0xf0550000 00024694 00000329 0 000 stop 0xf0550350 crond 0xd3e84000 00024695 00024694 0 001 stop 0xd3e84350 news.daily 0xdc4c0000 00027343 00000329 0 000 stop 0xdc4c0350 crond 0xcdec2000 00027344 00027343 0 000 stop 0xcdec2350 run-parts 0xe3398000 00027457 00027344 0 001 stop 0xe3398350 slocate.cron 0xe1f6c000 00027458 00027457 1 000 run 0xe1f6c350*slocate 0xd3c90000 00001382 00024695 0 001 stop 0xd3c90350 news.daily 0xe42ce000 00001383 00024695 0 001 stop 0xe42ce350 sed 0xda4b6000 00001384 00001382 1 001 run 0xda4b6350 expire 0xd02f8000 00001385 00028283 0 000 stop 0xd02f8350 sleep [0]kdb> go Oops: 0002 eth0: card reports no resources. CPU: 1 EIP: 0010:[] EFLAGS: 00010002 eax: 00000000 ebx: 00000004 ecx: 00000001 edx: ef7ab8f4 esi: ef7ab944 edi: 00000004 ebp: da4b7cb4 esp: da4b7ca8 ds: 0018 es: 0018 ss: 0018 Process expire (pid: 1384, stackpage=da4b7000) Stack: e1008a7c ef7ab944 00000004 da4b7cd4 c01be6bb 00000004 00000000 ef7ab944 ef7ab95c da4b7d1c 00000000 da4b7ce8 c01c7e7d e1008a94 00000002 ef7ab944 da4b7d08 c01c83a8 ef7ab944 00000002 ef7ab944 c0339660 f88522e0 e1008b9c Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 fe 4b 24 0f 88 22 dd 0a 00 83 3b 00 74 22 8d 7b 24 8d 73 --------------3E2A8AE8C9E625A1473E58D6-- From owner-linux-xfs@oss.sgi.com Tue Jan 23 11:58:21 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 11:58:02 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:27718 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 11:57:38 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA04096 for ; Tue, 23 Jan 2001 11:57:37 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA563534 for ; Tue, 23 Jan 2001 13:56:22 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA06503 for ; Tue, 23 Jan 2001 13:56:22 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0NJuY632618; Tue, 23 Jan 2001 13:56:34 -0600 Message-Id: <200101231956.f0NJuY632618@jen.americas.sgi.com> Date: Tue, 23 Jan 2001 13:56:34 -0600 Subject: TAKE - Locking fixes for the xfs I/O path To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This fixes xfs_strategy so that it does not attempt to allocate space for a delalloc extent when that extent has been truncated out of the file. This was panicing debug kernels as it became a true allocation request and the transaction had no associated space allocation. This will protect against truncations, but not against someone doing hole punching which may show up with dmapi. Also remove the rwlock from the page read and write paths. This removes some deadlocks, and lessens contention. The writepage path was safe, the readpage path needed to cope with racing with a delalloc extent creation. Finally change the flags on memory allocations which happen under filesystem locks (usually the xfs inode lock) to use GFP_BUFFER rather than GFP_KERNEL. This stops the memory reclaim threads from pushing back into the filesystem again to free memory and deadlocking. I have not yet managed to deadlock a system due to memory pressure with these changes. dbench throughput also appears to improve. Date: Tue Jan 23 11:48:45 PST 2001 Workarea: 128.162.184.86:/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:82766a linux/fs/xfs/linux/xfs_lrw.c - 1.73 - Change strategy to atomically restrain extent conversions to the current last block in the extents, avoiding the problem where another thread truncates the file during the strategy call. linux/fs/xfs/linux/xfs_iops.c - 1.92 - Remove linvfs_read_full_page and linvfs_write_full_page, we now go direct to pagebuf functions without getting the rwlock. linux/include/linux/page_buf.h - 1.70 - remove pagebuf_sethole prototype - it is gone. linux/fs/pagebuf/page_buf.c - 1.47 - For metadata pagebuf allocations use GFP_BUFFER not GFP_KERNEL, we often have a filesystem lock here and there is deadlock potential with GFP_KERNEL. linux/fs/pagebuf/page_buf_io.c - 1.44 - Cleanup read_full_page and change write_full_page to unlock the page on completion. linux/fs/xfs/support/kmem.c - 1.5 - use GFP_BUFFER not GFP_KERNEL for memory allocations to avoid possible deadlock from memory reclaim code pushing back into the filesystem. From owner-linux-xfs@oss.sgi.com Tue Jan 23 14:04:42 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 14:04:32 -0800 Received: from maynard.mail.mindspring.net ([207.69.200.243]:37912 "EHLO maynard.mail.mindspring.net") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 14:04:17 -0800 Received: from mindspring.com (user-37ka24s.dialup.mindspring.com [207.69.8.156]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA07178 for ; Tue, 23 Jan 2001 17:04:15 -0500 (EST) Message-ID: <3A6E0251.65BD4FB7@mindspring.com> Date: Tue, 23 Jan 2001 17:14:41 -0500 From: Danny Reply-To: dcox@connex.com Organization: Connex Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-XFS Subject: Buffer Head Corruption Found Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing All, I just spent today performing a pseudo binary search for a buffer head corruption I have been experiencing with XFS and RAID5. I have no idea why it only happens in this instance, as you'll see. In page_buf.c, around line 1424, a call is made to kmem_cache_alloc (). The short story is: at least one pointer is returned that is already in use! I wrote a function that steps through the buffer_head lists, and checks for b_next_free == NULL. Since it's a circular list, that should never be true. However, after the call to kmem_cache_alloc, and the subsequent 'memset (bh, 0,...)', I have my NULL. This also is the source of most of my Oopes from within buffer.c. Those functions are not expecting a NULL in b_next_free at all ;-). So: I've found it, but I have no idea why kmem_cache_alloc would return a previously used bh, nor what to do about it. Ideas? Thanks! -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill Danny From owner-linux-xfs@oss.sgi.com Tue Jan 23 16:18:42 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 16:18:32 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38464 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 16:18:18 -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 QAA02343 for ; Tue, 23 Jan 2001 16:27:15 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01486 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 24 Jan 2001 11:17:00 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA90459 for ; Wed, 24 Jan 2001 11:16:59 +1100 (EST) Message-Id: <200101240016.LAA90459@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com X-URL: http://zoic.org/dxm Subject: current dev kernel unstable Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 11:16:58 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing t-o-t kernel this morning, same setup as last time, XFS is reliably flakey. 3 out of 3 fail, twice in test 001 (!), once in test 014. fuzzy login: Start mounting filesystem: sd(8,6) Ending clean XFS mount for filesystem: sd(8,6) Start mounting filesystem: sd(8,6) Ending clean XFS mount for filesystem: sd(8,6) Entering kdb (current=0xc125e000, pid 0) on processor 1 due to Keyboard Entry [1]kdb> bt EBP EIP Function(args) 0xc125ffa4 0xc01071ff default_idle+0x2f kernel .text 0xc0100000 0xc01071d0 0xc0107208 0xc125ffb8 0xc0107272 cpu_idle+0x42 kernel .text 0xc0100000 0xc0107230 0xc0107288 [1]kdb> cpu 0 Entering kdb (current=0xc1806000, pid 726) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc1807de0 0xc012ae9f kmem_cache_zalloc+0xcb (0xc031b148, 0x3, 0xc0319c00) kernel .text 0xc0100000 0xc012add4 0xc012aebc 0xc1807e00 0xc8828894 [xfs_support]kmem_zone_zalloc+0x34 (0xc031b148, 0x1) xfs_support .text 0xc8828060 0xc8828860 0xc8828970 0xc1807e14 0xc8982c6b [xfs]xfs_trans_alloc+0x37 (0xc0319c00, 0xf) xfs .text 0xc8926060 0xc8982c34 0xc8982ca8 0xc1807f20 0xc8998a67 [xfs]xfs_strategy+0x493 (0xc6929b0c, 0x53000, 0x0, 0x1000, 0x10002) xfs .text 0xc8926060 0xc89985d4 0xc89990b0 0xc1807f58 0xc8997039 [xfs]linvfs_pb_bmap+0xa5 (0xc0ed3a20, 0x53000, 0x0, 0x1000, 0xc1807f9c) xfs .text 0xc8926060 0xc8996f94 0xc8997048 0xc1807fb8 0xc88335e6 [pagebuf]pagebuf_delalloc_convert+0x4e (0xc11f6e08, 0xc16f6000) pagebuf .text 0xc882e060 0xc8833598 0xc883377c 0xc1807fec 0xc8833970 [pagebuf]page_cleaner_daemon+0x1f4 pagebuf .text 0xc882e060 0xc883377c 0xc8833a50 0xc0107547 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107524 0xc010755c ----- XFS assertion failed: count_fsb, file: xfs_lrw.c, line: 1056 kernel BUG at debug.c:48! Entering kdb (current=0xc3fb4000, pid 754) on processor 0 Panic: invalid operand due to panic @ 0xc8828d75 eax = 0x0000001a ebx = 0x00000020 ecx = 0x00000001 edx = 0x00000000 esi = 0x00000000 edi = 0x00010002 esp = 0xc3fb5e04 eip = 0xc8828d75 ebp = 0xc3fb5e10 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc3fb5dd0 [0]kdb> bt EBP EIP Function(args) 0xc3fb5e10 0xc8828d75 [xfs_support]assfail+0x2d (0xc89b5cc4, 0xc89b58b7, 0x420) xfs_support .text 0xc8828060 0xc8828d48 0xc8828d7c 0xc3fb5f20 0xc8998f42 [xfs]xfs_strategy+0x96e (0xc35d329c, 0x20000, 0x0, 0x1000, 0x10002) xfs .text 0xc8926060 0xc89985d4 0xc89990b0 0xc3fb5f58 0xc8997039 [xfs]linvfs_pb_bmap+0xa5 (0xc3818660, 0x20000, 0x0, 0x1000, 0xc3fb5f9c) xfs .text 0xc8926060 0xc8996f94 0xc8997048 0xc3fb5fb8 0xc88335e6 [pagebuf]pagebuf_delalloc_convert+0x4e (0xc10eb760, 0xc13a0000) pagebuf .text 0xc882e060 0xc8833598 0xc883377c 0xc3fb5fec 0xc8833970 [pagebuf]page_cleaner_daemon+0x1f4 pagebuf .text 0xc882e060 0xc883377c 0xc8833a50 0xc0107547 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107524 0xc010755c ---------------- XFS assertion failed: count_fsb, file: xfs_lrw.c, line: 1056 kernel BUG at debug.c:48! Entering kdb (current=0xc401a000, pid 726) on processor 1 Panic: invalid operand due to panic @ 0xc8828d75 eax = 0x0000001a ebx = 0x00005b16 ecx = 0x00000001 edx = 0x00000000 esi = 0x00000000 edi = 0x00010002 esp = 0xc401be04 eip = 0xc8828d75 ebp = 0xc401be10 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc401bdd0 [1]kdb> bt EBP EIP Function(args) 0xc401be10 0xc8828d75 [xfs_support]assfail+0x2d (0xc89b5cc4, 0xc89b58b7, 0x420) xfs_support .text 0xc8828060 0xc8828d48 0xc8828d7c 0xc401bf20 0xc8998f42 [xfs]xfs_strategy+0x96e (0xc13b2b8c, 0x5b1d000, 0x0, 0x1000, 0x10002) xfs .text 0xc8926060 0xc89985d4 0xc89990b0 0xc401bf58 0xc8997039 [xfs]linvfs_pb_bmap+0xa5 (0xc7d3b080, 0x5b1d000, 0x0, 0x1000, 0xc401bf9c) xfs .text 0xc8926060 0xc8996f94 0xc8997048 0xc401bfb8 0xc88335e6 [pagebuf]pagebuf_delalloc_convert+0x4e (0xc1103118, 0xc5046000) pagebuf .text 0xc882e060 0xc8833598 0xc883377c 0xc401bfec 0xc8833970 [pagebuf]page_cleaner_daemon+0x1f4 pagebuf .text 0xc882e060 0xc883377c 0xc8833a50 0xc0107547 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107524 0xc010755c [1]kdb> From owner-linux-xfs@oss.sgi.com Tue Jan 23 16:29:32 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 16:29:11 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:53781 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 16:29:05 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA26226 for ; Tue, 23 Jan 2001 16:28:07 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA63356; Tue, 23 Jan 2001 16:23:35 -0800 (PST) Message-ID: <3A6E2178.7BF21108@sgi.com> Date: Tue, 23 Jan 2001 16:27:36 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Moore CC: linux-xfs@oss.sgi.com Subject: Re: current dev kernel unstable References: <200101240016.LAA90459@clouds.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore wrote: > > t-o-t kernel this morning, same setup as last time, XFS is reliably > flakey. 3 out of 3 fail, twice in test 001 (!), once in test 014. > > [ ...] Hmm. You don't seem to have some of the recent changes. The following line in xfs_lrw.c is from RCS revision 1.72, latest is revision 1.73 ... and it was part of a larger mod in order to fix problems you reported earlier. Can you please p_tupdate? thanks, ananth. > > XFS assertion failed: count_fsb, file: xfs_lrw.c, line: 1056 > kernel BUG at debug.c:48! From owner-linux-xfs@oss.sgi.com Tue Jan 23 16:46:01 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 16:45:42 -0800 Received: from lucy.physik.TU-Cottbus.De ([141.43.75.1]:8303 "HELO lucy.physik.tu-cottbus.de") by oss.sgi.com with SMTP id ; Tue, 23 Jan 2001 16:45:25 -0800 Received: (qmail 478727 invoked from network); 24 Jan 2001 00:45:17 -0000 Received: from strauss.physik.tu-cottbus.de (george@141.43.75.28) by lucy.physik.tu-cottbus.de with SMTP; 24 Jan 2001 00:45:17 -0000 Date: Wed, 24 Jan 2001 01:45:17 +0100 (CET) From: Ionut Georgescu To: linux-xfs@oss.sgi.com Subject: ACL files missing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi, I've just made a cvs update and some files are missing: ext_attr.c, noposix_acl.c, posix_acl.c As I understood from the list archive these files have already been checked in 'somewhere', but not for us, the outside world :)) Regards, Ionut *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * ICQ: 38973105 * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Tue Jan 23 17:26:22 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 17:26:12 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:22367 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 17:25:55 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA04028 for ; Tue, 23 Jan 2001 17:25:49 -0800 (PST) mail_from (dxm@clouds.melbourne.sgi.com) Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02065 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 24 Jan 2001 12:24:36 +1100 Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA92706 for ; Wed, 24 Jan 2001 12:24:33 +1100 (EST) Message-Id: <200101240124.MAA92706@clouds.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 Subject: dev kernel NOT unstable (was: Re: current dev kernel unstable) In-reply-to: Your message of "Wed, 24 Jan 2001 11:16:58 +1100." <200101240016.LAA90459@clouds.melbourne.sgi.com> Mime-Version: 1.0 To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 12:24:33 +1100 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Daniel Moore writes: => => t-o-t kernel this morning, same setup as last time, XFS is reliably => flakey. 3 out of 3 fail, twice in test 001 (!), once in test 014. Whoops - I stuffed up - the kernel in question had a dodgey patch against it. Everything seems OK now. ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jan 23 18:46:22 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 18:46:13 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:25974 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 18:45:59 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08726 for ; Tue, 23 Jan 2001 18:45:54 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA567424; Tue, 23 Jan 2001 20:44:40 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA59387; Tue, 23 Jan 2001 20:44:40 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0O2juJ02196; Tue, 23 Jan 2001 20:45:56 -0600 Message-Id: <200101240245.f0O2juJ02196@jen.americas.sgi.com> To: Ionut Georgescu cc: linux-xfs@oss.sgi.com Subject: Re: ACL files missing In-reply-to: References: Comments: In-reply-to Ionut Georgescu message dated "Wed, 24 Jan 2001 01:45:17 +0100." Date: Tue, 23 Jan 2001 20:45:56 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Yep, this does appear to be the case - I have the same files missing all from the fs directory. Russell, are you out there. Steve > Hi, > > I've just made a cvs update and some files are missing: > > ext_attr.c, noposix_acl.c, posix_acl.c > > As I understood from the list archive these files have already been > checked in 'somewhere', but not for us, the outside world :)) > > Regards, > Ionut > From owner-linux-xfs@oss.sgi.com Tue Jan 23 20:04:12 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 20:03:53 -0800 Received: from lips.borg.umn.edu ([160.94.232.50]:5137 "EHLO lips.borg.umn.edu") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 20:03:30 -0800 Received: from thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id f0O43JQ48178; Tue, 23 Jan 2001 22:03:23 -0600 (CST) Message-ID: <3A6E5401.A9B2E201@thebarn.com> Date: Tue, 23 Jan 2001 22:03:14 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Ionut Georgescu , linux-xfs@oss.sgi.com Subject: Re: ACL files missing References: <200101240245.f0O2juJ02196@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: > Yep, this does appear to be the case - I have the same files missing > all from the fs directory. Russell, are you out there. Just got in. Ok where these files missing from? suppose I can go hunt them down. > > > Steve > > > Hi, > > > > I've just made a cvs update and some files are missing: > > > > ext_attr.c, noposix_acl.c, posix_acl.c > > > > As I understood from the list archive these files have already been > > checked in 'somewhere', but not for us, the outside world :)) > > > > Regards, > > Ionut > > -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Tue Jan 23 23:22:24 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 23:22:04 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:52034 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 23:21:33 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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 XAA02287 for ; Tue, 23 Jan 2001 23:21:24 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id BAA88409 for ; Wed, 24 Jan 2001 01:20:09 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f0O7J8Y06417 for linux-xfs@oss.sgi.com; Wed, 24 Jan 2001 01:19:08 -0600 Date: Wed, 24 Jan 2001 01:19:08 -0600 From: Russell Cattelan Message-Id: <200101240719.f0O7J8Y06417@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 23 23:18:47 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82838a cmd/etherboot/3c509.c - 1.2 cmd/etherboot/3c509.h - 1.2 cmd/etherboot/Config - 1.2 cmd/etherboot/Makefile - 1.2 cmd/etherboot/a.out.h - 1.2 cmd/etherboot/ansiesc.c - 1.2 cmd/etherboot/bootmenu.c - 1.2 cmd/etherboot/config.c - 1.2 cmd/etherboot/config.h - 1.2 cmd/etherboot/cs89x0.c - 1.2 cmd/etherboot/cs89x0.h - 1.2 cmd/etherboot/eepro100.c - 1.2 cmd/etherboot/epic100.c - 1.2 cmd/etherboot/epic100.h - 1.2 cmd/etherboot/etherboot.h - 1.2 cmd/etherboot/floppy.c - 1.2 cmd/etherboot/floppyload.asm - 1.2 cmd/etherboot/i82586.c - 1.2 cmd/etherboot/lance.c - 1.2 cmd/etherboot/linuxdef.h - 1.2 cmd/etherboot/linuxloader.c - 1.2 cmd/etherboot/loader.asm - 1.2 cmd/etherboot/loader.inc - 1.2 cmd/etherboot/lzhuf.c - 1.2 cmd/etherboot/main.c - 1.2 cmd/etherboot/makerom.c - 1.2 cmd/etherboot/md5.c - 1.2 cmd/etherboot/misc.c - 1.2 cmd/etherboot/nic.h - 1.2 cmd/etherboot/ns8390.c - 1.2 cmd/etherboot/ns8390.h - 1.2 cmd/etherboot/objdump86.c - 1.2 cmd/etherboot/pci.c - 1.2 cmd/etherboot/pci.h - 1.2 cmd/etherboot/smc9000.c - 1.2 cmd/etherboot/smc9000.h - 1.2 cmd/etherboot/start.S - 1.2 cmd/etherboot/test.c - 1.2 cmd/etherboot/tiara.c - 1.2 cmd/etherboot/zloader.asm - 1.2 cmd/mknbi-linux/ChangeLog - 1.2 cmd/mknbi-linux/Makefile - 1.2 cmd/mknbi-linux/Makefile.in - 1.2 cmd/mknbi-linux/common.h - 1.2 cmd/mknbi-linux/config.h - 1.2 cmd/mknbi-linux/eth-select.patch - 1.2 cmd/mknbi-linux/first.S - 1.2 cmd/mknbi-linux/first.inc - 1.2 cmd/mknbi-linux/first_c.c - 1.2 cmd/mknbi-linux/makec.c - 1.2 cmd/mknbi-linux/mknbi.c - 1.2 cmd/mknbi-linux/mknbi.h - 1.2 cmd/mknbi-linux/mknbi.man - 1.2 cmd/mknbi-linux/version.h - 1.2 cmd/mknbi-linux/version.h.in - 1.2 cmd/lockstat/lockstat.c - 1.5 cmd/lockstat/Makefile - 1.4 - Toss unused directories. From owner-linux-xfs@oss.sgi.com Tue Jan 23 23:28:05 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 23:27:54 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:20549 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 23:27:32 -0800 Received: from ledzep.americas.sgi.com (relay.cray.com [137.38.226.97]) 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 XAA06692 for ; Tue, 23 Jan 2001 23:27:29 -0800 (PST) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id BAA72233 for ; Wed, 24 Jan 2001 01:26:14 -0600 (CST) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.0/8.11.0) id f0O7PER07122; Wed, 24 Jan 2001 01:25:14 -0600 Date: Wed, 24 Jan 2001 01:25:14 -0600 From: Russell Cattelan Message-Id: <200101240725.f0O7PER07122@gibble.americas.sgi.com> Subject: TAKE - To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Tue Jan 23 23:24:31 PST 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta2 Author: cattelan Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:82838a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta2 Modid: 2.4.x-xfs-beta2:slinx:82838a cmd/etherboot/3c509.c - 1.2 cmd/etherboot/3c509.h - 1.2 cmd/etherboot/Config - 1.2 cmd/etherboot/Makefile - 1.2 cmd/etherboot/a.out.h - 1.2 cmd/etherboot/ansiesc.c - 1.2 cmd/etherboot/bootmenu.c - 1.2 cmd/etherboot/config.c - 1.2 cmd/etherboot/config.h - 1.2 cmd/etherboot/cs89x0.c - 1.2 cmd/etherboot/cs89x0.h - 1.2 cmd/etherboot/eepro100.c - 1.2 cmd/etherboot/epic100.c - 1.2 cmd/etherboot/epic100.h - 1.2 cmd/etherboot/etherboot.h - 1.2 cmd/etherboot/floppy.c - 1.2 cmd/etherboot/floppyload.asm - 1.2 cmd/etherboot/i82586.c - 1.2 cmd/etherboot/lance.c - 1.2 cmd/etherboot/linuxdef.h - 1.2 cmd/etherboot/linuxloader.c - 1.2 cmd/etherboot/loader.asm - 1.2 cmd/etherboot/loader.inc - 1.2 cmd/etherboot/lzhuf.c - 1.2 cmd/etherboot/main.c - 1.2 cmd/etherboot/makerom.c - 1.2 cmd/etherboot/md5.c - 1.2 cmd/etherboot/misc.c - 1.2 cmd/etherboot/nic.h - 1.2 cmd/etherboot/ns8390.c - 1.2 cmd/etherboot/ns8390.h - 1.2 cmd/etherboot/objdump86.c - 1.2 cmd/etherboot/pci.c - 1.2 cmd/etherboot/pci.h - 1.2 cmd/etherboot/smc9000.c - 1.2 cmd/etherboot/smc9000.h - 1.2 cmd/etherboot/start.S - 1.2 cmd/etherboot/test.c - 1.2 cmd/etherboot/tiara.c - 1.2 cmd/etherboot/zloader.asm - 1.2 cmd/mknbi-linux/ChangeLog - 1.2 cmd/mknbi-linux/Makefile - 1.2 cmd/mknbi-linux/Makefile.in - 1.2 cmd/mknbi-linux/common.h - 1.2 cmd/mknbi-linux/config.h - 1.2 cmd/mknbi-linux/eth-select.patch - 1.2 cmd/mknbi-linux/first.S - 1.2 cmd/mknbi-linux/first.inc - 1.2 cmd/mknbi-linux/first_c.c - 1.2 cmd/mknbi-linux/makec.c - 1.2 cmd/mknbi-linux/mknbi.c - 1.2 cmd/mknbi-linux/mknbi.h - 1.2 cmd/mknbi-linux/mknbi.man - 1.2 cmd/mknbi-linux/version.h - 1.2 cmd/mknbi-linux/version.h.in - 1.2 cmd/lockstat/lockstat.c - 1.5 cmd/lockstat/Makefile - 1.4 - Merge of 2.4.x-xfs:slinx:82838a by cattelan. Toss unused directories. From owner-linux-xfs@oss.sgi.com Tue Jan 23 23:45:54 2001 Received: by oss.sgi.com id ; Tue, 23 Jan 2001 23:45:34 -0800 Received: from [212.247.11.130] ([212.247.11.130]:10485 "EHLO server.poldata.net") by oss.sgi.com with ESMTP id ; Tue, 23 Jan 2001 23:45:14 -0800 Received: from micke ([192.168.3.25]) by server.poldata.net (8.11.0/8.11.0) with SMTP id f0O8oGk05904 for ; Wed, 24 Jan 2001 09:50:16 +0100 Message-ID: <001c01c085d9$cf363e90$1903a8c0@poldata.net> From: "Michael Jonsson" To: Subject: cdrom problem Date: Wed, 24 Jan 2001 08:46:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C085E2.24E75F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C085E2.24E75F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I can not mount the ide cdrom after the installtion with the xfs-test5 = install cdrom, I can not find any device in the /dev for the cdrom..... How can I make a device for the cdrom ???? /Mike ------=_NextPart_000_0019_01C085E2.24E75F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I can not mount the ide cdrom after the = installtion=20 with the xfs-test5 install cdrom,
I can not find any device in the /dev = for the=20 cdrom.....
 
How can I make a device for the cdrom=20 ????
 
/Mike
------=_NextPart_000_0019_01C085E2.24E75F60-- From owner-linux-xfs@oss.sgi.com Wed Jan 24 05:33:25 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 05:33:16 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:60165 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 05:32:54 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id LAA15315 for ; Wed, 24 Jan 2001 11:32:19 -0200 Date: Wed, 24 Jan 2001 09:42:42 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: linux-xfs@oss.sgi.com Subject: try_to_swap_out() clears pte before checking for delalloc page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Minor issue, anyway... In the XFS tree, file mm/vmscan.c, function try_to_swap_out(); /* From this point on, the odds are that we're going to * nuke this pte, so read and clear the pte. This hook * is needed on CPUs which update the accessed and dirty * bits in hardware. */ pte = ptep_get_and_clear(page_table); flush_tlb_page(vma, address); if (DelallocPage(page)) { goto out_unlock_restore; } During pte aging & unmapping activity, each scanned pte pointing to a delalloc page will be cleared (ptep_get_and_clear), its TLB entry will be invalidated and the pte will be mapped again. The DelallocPage check can be moved before the pte&tlb clearing to avoid the unecessary work. Russell, you're supposed to merge new kernels, right? Could you please change that while merging ? (the code changed anyway so you'll have to touch it) Thanks From owner-linux-xfs@oss.sgi.com Wed Jan 24 07:36:15 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 07:35:56 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:10054 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 07:35:49 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07911 for ; Wed, 24 Jan 2001 07:35:31 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA572541; Wed, 24 Jan 2001 09:34:14 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA44728; Wed, 24 Jan 2001 09:34:14 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0OFZDY02802; Wed, 24 Jan 2001 09:35:14 -0600 Message-Id: <200101241535.f0OFZDY02802@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Michael Jonsson" cc: linux-xfs@oss.sgi.com Subject: Re: cdrom problem In-Reply-To: Message from "Michael Jonsson" of "Wed, 24 Jan 2001 08:46:29 +0100." <001c01c085d9$cf363e90$1903a8c0@poldata.net> Date: Wed, 24 Jan 2001 09:35:13 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > This is a multi-part message in MIME format. > > ------=_NextPart_000_0019_01C085E2.24E75F60 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > I can not mount the ide cdrom after the installtion with the xfs-test5 = > install cdrom, > I can not find any device in the /dev for the cdrom..... > > How can I make a device for the cdrom ???? > > /Mike > I bet devfs is mounted - which will mean devices not being present unless the driver is in the kernel. Also the ide-cdrom is probably a module in this kernel. Try doing a modprobe ide-cd. Your cdrom will show up as /dev/cdroms/cdrom1 (or something like that). I was going to say you should upgrade to the latest RPMS, however, if you are using images from this directory ftp://oss.sgi.com/projects/xfs/download/PreRelease-0.9 you are already doing so (the test-5 confused me). If you rebuild the kernel without devfs then things will go back to how you expect them to be - I would also build into the kernel all the components you use regularly - ide/scsi drivers, xfs, iso9660 etc and do away with the initial ramdisk. It will boot much faster. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 24 07:50:46 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 07:50:36 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:10502 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 07:50:09 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id NAA16133; Wed, 24 Jan 2001 13:49:39 -0200 Date: Wed, 24 Jan 2001 12:00:02 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Locking fixes for the xfs I/O path In-Reply-To: <200101231956.f0NJuY632618@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 23 Jan 2001, Steve Lord wrote: > Finally change the flags on memory allocations which happen under filesystem > locks (usually the xfs inode lock) to use GFP_BUFFER rather than GFP_KERNEL. > This stops the memory reclaim threads from pushing back into the filesystem > again to free memory and deadlocking. > > I have not yet managed to deadlock a system due to memory pressure with > these changes. dbench throughput also appears to improve. Steve, Have to check if, under 2.4.1, with low memory machines under heavy IO no XFS allocations fails. We are not waiting for kswapd anymore, so the !__GFP_IO allocations are more fragile. From owner-linux-xfs@oss.sgi.com Wed Jan 24 07:52:15 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 07:51:56 -0800 Received: from bru5-smtp-out1.uunet.be ([194.7.1.5]:37063 "EHLO bru5-smtp-out1.uunet.be") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 07:51:44 -0800 Received: from gate.vum.be (firewall.vum.be [194.7.240.162]) by bru5-smtp-out1.uunet.be (8.11.2/8.11.2) with SMTP id f0OFpKf23873; Wed, 24 Jan 2001 16:51:21 +0100 (MET) Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id QAA09441; Wed, 24 Jan 2001 16:54:05 +0100 (MET) Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1]) by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id QAA15331; Wed, 24 Jan 2001 16:50:45 +0100 Message-ID: <3A6EF9D5.B52629BC@vum.be> Date: Wed, 24 Jan 2001 16:50:45 +0100 From: kris buggenhout X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: cdrom problem References: <200101241535.f0OFZDY02802@jen.americas.sgi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing U3RldmUgTG9yZCB3cm90ZToNCg0KPiA+IFRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1lc3NhZ2Ug aW4gTUlNRSBmb3JtYXQuDQo+ID4NCj4gPiAtLS0tLS09X05leHRQYXJ0XzAwMF8wMDE5XzAx QzA4NUUyLjI0RTc1RjYwDQo+ID4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KPiA+ICAg ICAgIGNoYXJzZXQ9Imlzby04ODU5LTEiDQo+ID4gQ29udGVudC1UcmFuc2Zlci1FbmNvZGlu ZzogcXVvdGVkLXByaW50YWJsZQ0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIGNhbiBub3Qg bW91bnQgdGhlIGlkZSBjZHJvbSBhZnRlciB0aGUgaW5zdGFsbHRpb24gd2l0aCB0aGUgeGZz LXRlc3Q1ID0NCj4gPiBpbnN0YWxsIGNkcm9tLA0KPiA+IEkgY2FuIG5vdCBmaW5kIGFueSBk ZXZpY2UgaW4gdGhlIC9kZXYgZm9yIHRoZSBjZHJvbS4uLi4uDQo+ID4NCj4gPiBIb3cgY2Fu IEkgbWFrZSBhIGRldmljZSBmb3IgdGhlIGNkcm9tID8/Pz8NCj4gPg0KPiA+IC9NaWtlDQo+ ID4NCj4NCj4gSSBiZXQgZGV2ZnMgaXMgbW91bnRlZCAtIHdoaWNoIHdpbGwgbWVhbiBkZXZp Y2VzIG5vdCBiZWluZyBwcmVzZW50IHVubGVzcw0KPiB0aGUgZHJpdmVyIGlzIGluIHRoZSBr ZXJuZWwuIEFsc28gdGhlIGlkZS1jZHJvbSBpcyBwcm9iYWJseSBhIG1vZHVsZSBpbg0KPiB0 aGlzIGtlcm5lbC4gVHJ5IGRvaW5nIGEgbW9kcHJvYmUgaWRlLWNkLiBZb3VyIGNkcm9tIHdp bGwgc2hvdyB1cCBhcw0KPiAvZGV2L2Nkcm9tcy9jZHJvbTEgKG9yIHNvbWV0aGluZyBsaWtl IHRoYXQpLg0KPg0KPiBJIHdhcyBnb2luZyB0byBzYXkgeW91IHNob3VsZCB1cGdyYWRlIHRv IHRoZSBsYXRlc3QgUlBNUywgaG93ZXZlciwgaWYgeW91DQo+IGFyZSB1c2luZyBpbWFnZXMg ZnJvbSB0aGlzIGRpcmVjdG9yeQ0KPg0KPiBmdHA6Ly9vc3Muc2dpLmNvbS9wcm9qZWN0cy94 ZnMvZG93bmxvYWQvUHJlUmVsZWFzZS0wLjkNCj4NCj4geW91IGFyZSBhbHJlYWR5IGRvaW5n IHNvICh0aGUgdGVzdC01IGNvbmZ1c2VkIG1lKS4NCj4NCj4gSWYgeW91IHJlYnVpbGQgdGhl IGtlcm5lbCB3aXRob3V0IGRldmZzIHRoZW4gdGhpbmdzIHdpbGwgZ28gYmFjayB0bw0KPiBo b3cgeW91IGV4cGVjdCB0aGVtIHRvIGJlIC0gSSB3b3VsZCBhbHNvIGJ1aWxkIGludG8gdGhl IGtlcm5lbCBhbGwNCj4gdGhlIGNvbXBvbmVudHMgeW91IHVzZSByZWd1bGFybHkgLSBpZGUv c2NzaSBkcml2ZXJzLCB4ZnMsIGlzbzk2NjANCj4gZXRjIGFuZCBkbyBhd2F5IHdpdGggdGhl IGluaXRpYWwgcmFtZGlzay4gSXQgd2lsbCBib290IG11Y2ggZmFzdGVyLg0KPg0KPiBTdGV2 ZQ0KDQp5YSB0aGF0cyBub3JtYWwgd2l0aCBkZXZmcyAuLi4NCg0Kd2l0aCB0aGUgYmV0YSBp c28ncyBldmVyeXRoaW5nIGlzIGNvbmZpZ3VyZWQgYXMgYSBtb2R1bGUuDQoNCnlvdSBoYXZl IHRvIGluc21vZCBjZHJvbSBtb2R1bGUsIHRoZW4gaWRlLWNkIC4uLiB0aGVuIGl0IHdvcmtz IC4uLg0KDQo= From owner-linux-xfs@oss.sgi.com Wed Jan 24 08:08:35 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 08:08:16 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:48939 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 08:08: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 IAA11211 for ; Wed, 24 Jan 2001 08:07:08 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA570583; Wed, 24 Jan 2001 10:06:49 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA74197; Wed, 24 Jan 2001 10:06:49 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0OG7mQ10240; Wed, 24 Jan 2001 10:07:48 -0600 Message-Id: <200101241607.f0OG7mQ10240@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: TAKE - Locking fixes for the xfs I/O path In-Reply-To: Message from Marcelo Tosatti of "Wed, 24 Jan 2001 12:00:02 -0200." Date: Wed, 24 Jan 2001 10:07:48 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > On Tue, 23 Jan 2001, Steve Lord wrote: > > > Finally change the flags on memory allocations which happen under filesyste > m > > locks (usually the xfs inode lock) to use GFP_BUFFER rather than GFP_KERNEL > . > > This stops the memory reclaim threads from pushing back into the filesystem > > again to free memory and deadlocking. > > > > I have not yet managed to deadlock a system due to memory pressure with > > these changes. dbench throughput also appears to improve. > > Steve, > > Have to check if, under 2.4.1, with low memory machines under heavy IO no > XFS allocations fails. > > We are not waiting for kswapd anymore, so the !__GFP_IO allocations are > more fragile. > Oh Joy! So even though the request flags say it is ok to sleep for memory, it can still fail? I was hoping we had found a way out of this hole. OK, I do see that GFP_BUFFER users are expected to cope with failure, looks like it is back to the drawing board here - xfs cannot cope with a non-robust memory allocator. What we really need is an interface which says go get some memory, and don't return until you have some, but do not bug me to free memory. The problem with the GFP flags is that they are an extremely large hammer - i.e. do not ask any filesystem for any memory is a bit over the top. Steve p.s. running with the try_to_swap_out change now. From owner-linux-xfs@oss.sgi.com Wed Jan 24 08:19:35 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 08:19:26 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:15878 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 08:19:03 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id OAA16339; Wed, 24 Jan 2001 14:18:31 -0200 Date: Wed, 24 Jan 2001 12:28:54 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Locking fixes for the xfs I/O path In-Reply-To: <200101241607.f0OG7mQ10240@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 24 Jan 2001, Steve Lord wrote: > > > > On Tue, 23 Jan 2001, Steve Lord wrote: > > > > > Finally change the flags on memory allocations which happen under filesyste > > m > > > locks (usually the xfs inode lock) to use GFP_BUFFER rather than GFP_KERNEL > > . > > > This stops the memory reclaim threads from pushing back into the filesystem > > > again to free memory and deadlocking. > > > > > > I have not yet managed to deadlock a system due to memory pressure with > > > these changes. dbench throughput also appears to improve. > > > > Steve, > > > > Have to check if, under 2.4.1, with low memory machines under heavy IO no > > XFS allocations fails. > > > > We are not waiting for kswapd anymore, so the !__GFP_IO allocations are > > more fragile. > > > > Oh Joy! So even though the request flags say it is ok to sleep for memory, it > can still fail? I was hoping we had found a way out of this hole. OK, I do > see that GFP_BUFFER users are expected to cope with failure, looks like it is > back to the drawing board here - xfs cannot cope with a non-robust memory > allocator. What we really need is an interface which says go get some memory, > and don't return until you have some, but do not bug me to free memory. The > problem with the GFP flags is that they are an extremely large hammer - i.e. > do not ask any filesystem for any memory is a bit over the top. Wait. We can call flush_dirty_buffers(0) for !__GFP_IO allocations. This will block them at ll_rw_block() which is ok since you're not going throught the filesystem codepath anymore. From owner-linux-xfs@oss.sgi.com Wed Jan 24 10:46:27 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 10:46:17 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3163 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 10:45:59 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA04158 for ; Wed, 24 Jan 2001 10:45:00 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA01077; Wed, 24 Jan 2001 10:44:20 -0800 (PST) Date: Wed, 24 Jan 2001 10:42:27 -0800 (PST) From: Tom Duffy To: kris buggenhout cc: Steve Lord , "linux-xfs@oss.sgi.com" Subject: Re: cdrom problem In-Reply-To: <3A6EF9D5.B52629BC@vum.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > ya thats normal with devfs ... > > with the beta iso's everything is configured as a module. > > you have to insmod cdrom module, then ide-cd ... then it works ... if you edit your /etc/devfsd.conf and put this line in, autoloading of modules should work: # Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD -tduffy From owner-linux-xfs@oss.sgi.com Wed Jan 24 12:31:47 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 12:31:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:11643 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 12:31:22 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20462 for ; Wed, 24 Jan 2001 12:30:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA577526 for ; Wed, 24 Jan 2001 14:30:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA36839 for ; Wed, 24 Jan 2001 14:30:05 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0OKV2516172; Wed, 24 Jan 2001 14:31:02 -0600 Message-Id: <200101242031.f0OKV2516172@jen.americas.sgi.com> Date: Wed, 24 Jan 2001 14:31:02 -0600 Subject: TAKE - tweak try_to_swap_out() To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Jan 24 12:30:25 PST 2001 Workarea: 128.162.184.86:/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:82867a linux/mm/vmscan.c - 1.46 - Reorder code in try_to_swap_out() based on suggestion from Marcelo Tosatti From owner-linux-xfs@oss.sgi.com Wed Jan 24 13:50:48 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 13:50:38 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:61209 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 13:50:27 -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 NAA01410 for ; Wed, 24 Jan 2001 13:49:25 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA578542; Wed, 24 Jan 2001 15:49:05 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA55505; Wed, 24 Jan 2001 15:49:04 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0OLo0n22823; Wed, 24 Jan 2001 15:50:01 -0600 Message-Id: <200101242150.f0OLo0n22823@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: dcox@connex.com cc: Linux-XFS Subject: Re: Buffer Head Corruption Found In-Reply-To: Message from Danny of "Tue, 23 Jan 2001 17:14:41 EST." <3A6E0251.65BD4FB7@mindspring.com> Date: Wed, 24 Jan 2001 15:50:00 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > All, > > I just spent today performing a pseudo binary search for a buffer head > corruption I have been experiencing with XFS and RAID5. I have no idea > why it only happens in this instance, as you'll see. > > In page_buf.c, around line 1424, a call is made to kmem_cache_alloc > (). The short story is: at least one pointer is returned that is > already in use! > > I wrote a function that steps through the buffer_head lists, and checks > for b_next_free == NULL. Since it's a circular list, that should never > be true. > > However, after the call to kmem_cache_alloc, and the subsequent 'memset > (bh, 0,...)', I have my NULL. This also is the source of most of my > Oopes from within buffer.c. Those functions are not expecting a NULL in > b_next_free at all ;-). > > So: I've found it, but I have no idea why kmem_cache_alloc would return > a previously used bh, nor what to do about it. Hmm, I am not sure how kmem_cache_alloc can do that either, is it not more likely that a buffer is being freed, but not removed from the list - i.e. the needle is in that other haystack over there. Maybe turning on memory poisoning will make things fall over faster - in mm/slab.c there are three defines : #define DEBUG 0 #define STATS 0 #define FORCED_DEBUG 0 I think you want to set the DEBUG flag to 1 Steve > > Ideas? > > Thanks! > > -- > "Men occasionally stumble over the truth, but most of them pick > themselves up and hurry off as if nothing had happened." > -- Winston Churchill > > Danny From owner-linux-xfs@oss.sgi.com Wed Jan 24 14:37:09 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:36:49 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40746 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:36:36 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06936 for ; Wed, 24 Jan 2001 14:45:36 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA69260 for ; Wed, 24 Jan 2001 14:35:19 -0800 (PST) Date: Wed, 24 Jan 2001 14:33:25 -0800 (PST) From: Tom Duffy To: Subject: xfs root installer error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I just got this error trying to install xfs root on my laptop (Dell Lattitude CPx). "Error mounting device hda1 as /boot: Invalid argument This most likely means this partition has not been formatted. Press OK to reboot your system." I have a 100M /boot (xfs) and a 256M swap, the rest of the disk at sda6 is / (xfs). It is IDE obviously. I can mount /boot as ext2 though in the miniroot...weird. -tduffy From owner-linux-xfs@oss.sgi.com Wed Jan 24 14:40:09 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:39:49 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:33065 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:39:39 -0800 Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA08333 for ; Wed, 24 Jan 2001 14:38:41 -0800 (PST) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.0/8.11.0) id f0OMd7A01997 for linux-xfs@oss.sgi.com; Wed, 24 Jan 2001 14:39:07 -0800 Date: Wed, 24 Jan 2001 14:39:07 -0800 From: Ananth Ananthanarayanan Message-Id: <200101242239.f0OMd7A01997@waco.engr.sgi.com> Subject: TAKE - cleanup unmarking delalloc pages To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Wed Jan 24 14:31:46 PST 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-tot The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:82883a linux/fs/pagebuf/page_buf_io.c - 1.45 - Cleanup accounting of delalloc pages. Also fix a bug where delalloc pages were left unmarked if the bmap(ALLOCATE) failed. From owner-linux-xfs@oss.sgi.com Wed Jan 24 14:41:09 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:40:50 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:55337 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:40:35 -0800 Received: from chuckle.americas.sgi.com (root@chuckle.americas.sgi.com [128.162.184.123]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA08494 for ; Wed, 24 Jan 2001 14:39:36 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0OMc8H26726; Wed, 24 Jan 2001 16:38:08 -0600 Message-ID: <3A6F5950.C8B1096E@thebarn.com> Date: Wed, 24 Jan 2001 16:38:08 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-5SGI_67smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: dcox@connex.com, Linux-XFS Subject: Re: Buffer Head Corruption Found References: <200101242150.f0OLo0n22823@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve Lord wrote: I should have responded to the earlier, I think I know what the problem is. XFS allocates private memory for buffer_heads used in meta data operations. If one these buffer_heads is fed to one of the buffer_head reclaim functions it will end up on one of the lists that manages the global buffer_head pool. This of course is an error and typically shows up when somebody tried to reference b_next_free. Basically we will need to find the spot where and XFS buffer_head is being reclaimed in a normal fashion rather than by our end_io routines. One place the could happen is in the default end_io function if the raid code is resetting this at some point this would be a good place to start looking. Note: Currently page_buf.c has this bit of code error: /* If we ever do get here then clean up what we already did */ for (itr=0; itr < cnt; itr++) { buffer_IO_error(psync->bh[itr]); } return err; This call to buffer_IO_error is an error, it would put the buffer_head on the lists. I don't think we ever hit this but you might want to take it out just as a first pass. > > > All, > > > > I just spent today performing a pseudo binary search for a buffer head > > corruption I have been experiencing with XFS and RAID5. I have no idea > > why it only happens in this instance, as you'll see. > > > > In page_buf.c, around line 1424, a call is made to kmem_cache_alloc > > (). The short story is: at least one pointer is returned that is > > already in use! > > > > I wrote a function that steps through the buffer_head lists, and checks > > for b_next_free == NULL. Since it's a circular list, that should never > > be true. > > > > However, after the call to kmem_cache_alloc, and the subsequent 'memset > > (bh, 0,...)', I have my NULL. This also is the source of most of my > > Oopes from within buffer.c. Those functions are not expecting a NULL in > > b_next_free at all ;-). > > > > So: I've found it, but I have no idea why kmem_cache_alloc would return > > a previously used bh, nor what to do about it. > > Hmm, I am not sure how kmem_cache_alloc can do that either, is it not more > likely that a buffer is being freed, but not removed from the list - i.e. the > needle is in that other haystack over there. Maybe turning on memory poisoning > will make things fall over faster - in mm/slab.c there are three defines : > > #define DEBUG 0 > #define STATS 0 > #define FORCED_DEBUG 0 > > I think you want to set the DEBUG flag to 1 > > Steve > > > > > Ideas? > > > > Thanks! > > > > -- > > "Men occasionally stumble over the truth, but most of them pick > > themselves up and hurry off as if nothing had happened." > > -- Winston Churchill > > > > Danny -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Jan 24 14:41:49 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:41:39 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3883 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:41:24 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06325 for ; Wed, 24 Jan 2001 14:50:23 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA77082 for ; Wed, 24 Jan 2001 14:40:07 -0800 (PST) Date: Wed, 24 Jan 2001 14:38:13 -0800 (PST) From: Tom Duffy To: Subject: Re: xfs root installer error 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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing never mind. my stupid mistake. i did not see that it had unset the format option on /boot. (why would this not be formatted by default). anyways, serves me right for using the graphical installation (much clearer on the text based install). things seem to be working better now. -tduffy On Wed, 24 Jan 2001, Tom Duffy wrote: > I just got this error trying to install xfs root on my laptop (Dell > Lattitude CPx). > > "Error mounting device hda1 as /boot: Invalid argument > > This most likely means this partition has not been formatted. > > Press OK to reboot your system." > > I have a 100M /boot (xfs) and a 256M swap, the rest of the disk at sda6 is > / (xfs). It is IDE obviously. I can mount /boot as ext2 though in the > miniroot...weird. > > -tduffy > From owner-linux-xfs@oss.sgi.com Wed Jan 24 14:45:39 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 14:45:19 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:62213 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 14:45:10 -0800 Received: from chuckle.americas.sgi.com (128-162-184-123.americas.sgi.com [128.162.184.123] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA06140 for ; Wed, 24 Jan 2001 14:45:09 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from thebarn.com (IDENT:cattelan@localhost.localdomain [127.0.0.1]) by chuckle.americas.sgi.com (8.11.0/8.11.0) with ESMTP id f0OMf6H26733; Wed, 24 Jan 2001 16:41:06 -0600 Message-ID: <3A6F5A01.6B1AADA0@thebarn.com> Date: Wed, 24 Jan 2001 16:41:05 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-5SGI_67smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Duffy CC: linux-xfs@oss.sgi.com Subject: Re: xfs root installer error References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Tom Duffy wrote: > > I just got this error trying to install xfs root on my laptop (Dell > Lattitude CPx). > > "Error mounting device hda1 as /boot: Invalid argument > > This most likely means this partition has not been formatted. > > Press OK to reboot your system." > > I have a 100M /boot (xfs) and a 256M swap, the rest of the disk at sda6 is > / (xfs). It is IDE obviously. I can mount /boot as ext2 though in the > miniroot...weird. I would appear the file system was never formatted. Look through the virtual terms after the installer says "formatting file system" you should find the output from mkfs.xfs. See if any error messages are there. It is possible 100m is a bit to small for the log size we are specifying. try bumping it to 128. > > -tduffy -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Jan 24 16:21:59 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 16:21:40 -0800 Received: from mail11.jump.net ([206.196.91.11]:14754 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 16:21:15 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0P0L8d21322; Wed, 24 Jan 2001 18:21:08 -0600 (CST) Message-ID: <3A6F7170.F230B688@sgi.com> Date: Wed, 24 Jan 2001 18:21:04 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Duffy CC: linux-xfs@oss.sgi.com Subject: Re: xfs root installer error References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Tom Duffy wrote: > > never mind. my stupid mistake. i did not see that it had unset the format > option on /boot. (why would this not be formatted by default). anyways, > serves me right for using the graphical installation (much clearer on the > text based install). > > things seem to be working better now. How did it get unset? I noticed, too, that my "/" wasn't selected for formatting by default, either. In any case, looks like you have found a bug - if XFS is selected, but format isn't, it still assumes that the fstab should be set up for XFS... Probably the best way around this would be to inactivate the "Use XFS" checkbox if the "format" box is unchecked. Right now there is no code in the installer to check for existing xfs filesystems (that's partly why upgrade is disabled), so if you don't format a particular partition, it doesn't know what FS is on it. Wonder if any of THIS is worth fixing prior to "real" release...? I could probably get it going tomorrow... -Eric From owner-linux-xfs@oss.sgi.com Wed Jan 24 17:32:50 2001 Received: by oss.sgi.com id ; Wed, 24 Jan 2001 17:32:30 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26177 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 Jan 2001 17:32:20 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04249 for ; Wed, 24 Jan 2001 17:41:19 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA82572 for linux-xfs@oss.sgi.com; Thu, 25 Jan 2001 12:30:55 +1100 (EST) Date: Thu, 25 Jan 2001 12:30:55 +1100 (EST) From: Nathan Scott Message-Id: <200101250130.MAA82572@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:82916a Date: Wed Jan 24 17:28:18 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/debian/rules - 1.2 cmd/attr/debian/rules - 1.2 cmd/dmapi/debian/rules - 1.2 cmd/xfsdump/debian/rules - 1.2 cmd/xfsprogs/debian/rules - 1.2 - revert to -O1 as -O2 is generating bad code ... gets us thru qa with a gcc 2.95.2 generated userspace. cmd/attr/Makepkgs - 1.2 cmd/dmapi/Makepkgs - 1.2 cmd/xfsprogs/Makepkgs - 1.2 - little out of date - sync up with other Makepkgs. cmd/dmapi/configure.in - 1.2 - need to check for handle.h header file before attempting a build. cmd/dmapi/libdm/dm_handle2path.c - 1.3 - fix compile error when using glibc 2.2 headers. cmd/xfstests/005 - 1.2 - minor porting issue wrt different versions of touch. cmd/xfstests/common.rc - 1.2 - minor porting issue - use awk not gawk. From owner-linux-xfs@oss.sgi.com Thu Jan 25 13:08:20 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 13:08:11 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12849 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 25 Jan 2001 13:07:52 -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 NAA03310 for ; Thu, 25 Jan 2001 13:16:52 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA589127 for ; Thu, 25 Jan 2001 15:06:35 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA48005 for ; Thu, 25 Jan 2001 15:06:35 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0PL7Lr05774; Thu, 25 Jan 2001 15:07:21 -0600 Message-Id: <200101252107.f0PL7Lr05774@jen.americas.sgi.com> Date: Thu, 25 Jan 2001 15:07:21 -0600 Subject: TAKE - simplify pagebuf code a little bit To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The original pagebuf structure had the ability to have an associated kiovec this vector has never been used with more than one element in it. This simplifies the code to just contain a single kiobuf pointer. Also remove some debug code and do a couple of minor tweaks in the pagebuf I/O path. Date: Thu Jan 25 13:04:55 PST 2001 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:83189a linux/fs/xfs/linux/xfs_lrw.c - 1.74 - remove debug code. linux/include/linux/page_buf.h - 1.71 - Remove kiovec capability from pagebuf. linux/kdb/modules/kdbm_pg.c - 1.26 - Remove kiovec capability from pagebuf linux/fs/pagebuf/page_buf.c - 1.48 - Remove kiovec capability from pagebuf, just use one kiobuf linux/fs/pagebuf/page_buf_io.c - 1.46 - remove debug code, change from kiovec to kiobuf From owner-linux-xfs@oss.sgi.com Thu Jan 25 13:52:50 2001 Received: by oss.sgi.com id ; Thu, 25 Jan 2001 13:52:30 -0800 Received: from hub-slc.firsthealth.com ([209.180.88.35]:16645 "HELO email.firsthealth.com") by oss.sgi.com with SMTP id ; Thu, 25 Jan 2001 13:52:20 -0800 Received: from 10.1.17.190 by email.firsthealth.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 25 Jan 2001 14:55:07 -0700 X-Server-Uuid: 4bf5d58d-3e8a-11d3-966e-00508b4fb619 Message-ID: <3A70A039.9070400@xnote.com> Date: Thu, 25 Jan 2001 14:52:57 -0700 From: "Vernon McPherron" Organization: Xnote.com Internet Services User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RH7.0 + XFS cd X-WSS-ID: 166E7F311737555-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I think the work that has been done to create a new system with FULL XFS (including / and /boot) is great! I'm thinking of modifing the installer just a bit more to include lvm support during the install. (although I do know that there may be issues with the root fs using lvm) The question that I've got is... Has anyone tried it yet, and what issues do you think I'd encounter? Actually the biggest question is, is the version of XFS on the install cd play well with LVM, or do I need to use the current tree from cvs? (I noticed that the lvm is built in the "stock" xfs kernel, but I think it was 0.8 final.) Thanks in advance. -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Fri Jan 26 05:48:14 2001 Received: by oss.sgi.com id ; Fri, 26 Jan 2001 05:48:04 -0800 Received: from [209.101.91.34] ([209.101.91.34]:14864 "EHLO mail.compro.net") by oss.sgi.com with ESMTP id ; Fri, 26 Jan 2001 05:47:50 -0800 Received: from compro.net (markh@PC120.COMPRO.NET [10.10.10.120]) by mail.compro.net (8.9.3/8.9.3) with ESMTP id KAA04590; Fri, 26 Jan 2001 10:03:18 -0500 Message-ID: <3A7181DB.9501E983@compro.net> Date: Fri, 26 Jan 2001 08:55:39 -0500 From: Mark Hounschell Reply-To: markh@compro.net Organization: Compro Computer Svcs. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Florin Andrei CC: linux-xfs@oss.sgi.com Subject: Re: xfs and reiserfs References: <3A6C653C.B1983FE7@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Florin Andrei wrote: > > Is it possible right now to have both XFS and ReiserFS in the kernel? > (and maybe use them simultaneously, on different partitions) If you never got an answer from all this I can now say that I do now have bothe working together on the same machine. What I had to do was first get the vanilla 2.4.0 kernel and all that Documentation/Changes tells you to get. Get and apply to reiser patch first. Next get and apply the XFS patch. Glibc-2.2 is also required and fileutils need to be comiled against it. So far everything looks good on this end. It was quite a bit of work but looks like it'll be worth the effort. Glibc-2.2.1 was the tricky part for me. Read and Read the FAQs again and again for bothe reiser and glibc............... -- Mark Hounschell markh@compro.net From owner-linux-xfs@oss.sgi.com Fri Jan 26 06:11:44 2001 Received: by oss.sgi.com id ; Fri, 26 Jan 2001 06:11:26 -0800 Received: from tux.mkp.net ([130.225.60.11]:54799 "EHLO tux.mkp.net") by oss.sgi.com with ESMTP id ; Fri, 26 Jan 2001 06:11:15 -0800 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.14 #2) id 14M9a6-0005AE-00; Fri, 26 Jan 2001 15:10:27 +0100 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id JAA14499; Fri, 26 Jan 2001 09:10:24 -0500 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Vernon McPherron" Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.0 + XFS cd References: <3A70A039.9070400@xnote.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 26 Jan 2001 09:10:24 -0500 In-Reply-To: <3A70A039.9070400@xnote.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing >>>>> "Vernon" == Vernon McPherron writes: [LVM vs. XFS] Vernon> The question that I've got is... Has anyone tried it yet, and Vernon> what issues do you think I'd encounter? Actually the biggest Vernon> question is, is the version of XFS on the install cd play well Vernon> with LVM, or do I need to use the current tree from cvs? (I Vernon> noticed that the lvm is built in the "stock" xfs kernel, but I Vernon> think it was 0.8 final.) Our prerelease is based upon a 2.4.0 kernel, however, I think our boot disk is still a test11 kernel. Russell/Eric, can you confirm this? In that case our boot disk has LVM 0.8final, while the installed kernel will be LVM 0.9. This shouldn't be a problem, as long as you use liblvm 0.8 for the installer work and put 0.9.1beta userland on the machine. A snapshot of LVM 0.9 was submitted Linus and applied to test12. This submission was not endorsed by the LVM development team and there are several issues with it. An official 0.9.1beta3 release just got out. I'm waiting for that to appear in the kernel before I start doing surgery to our tree. Most notably the XFS userland utilities (mkfs) will have to be updated to talk the 0.9 IOP protocol to extract stripe size etc. (You can always do that by hand, though). So, to be quite honest: The state of LVM in 2.4.0 is a mess. If I we're you I'd hold off for a week or two until the developers finish up a proper release. Otherwise grab 0.9.1beta tarball from sistina.com and apply that to an XFS prerelease source tree. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Fri Jan 26 06:27:14 2001 Received: by oss.sgi.com id ; Fri, 26 Jan 2001 06:26:54 -0800 Received: from ponyexpress5.csc.com ([208.219.64.204]:7089 "EHLO ponyexpress1.csc.com") by oss.sgi.com with ESMTP id ; Fri, 26 Jan 2001 06:26:27 -0800 Received: from va-fch32.csc.com ([20.1.107.10] helo=csc.com) by ponyexpress1.csc.com with esmtp (Exim 2.12 #1) id 14M9pT-0006rD-00 for linux-xfs@oss.sgi.com; Fri, 26 Jan 2001 09:26:20 -0500 Subject: Re: RH7.0 + XFS cd To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: gdoucet@csc.com Date: Fri, 26 Jan 2001 09:26:14 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 5.0.4a |July 24, 2000) at 01/26/2001 09:23:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I run a NFS fileserver with LVM 0.8 and XFS as root filesystem, I think the kernel is 2.4.0test11, work great. But I agree with Martin the development is a mess. I try to upgrade to 0.9.X and it fail at vgscan. I also use devfs and it does not work great with root filesystem + LVM, I have to import my disk on an orther machine to do any lv{remove|create}, But I think there is some discussion on the LVM mailing list for the problem with devfs. >>>>> "Vernon" == Vernon McPherron writes: [LVM vs. XFS] Vernon> The question that I've got is... Has anyone tried it yet, and Vernon> what issues do you think I'd encounter? Actually the biggest Vernon> question is, is the version of XFS on the install cd play well Vernon> with LVM, or do I need to use the current tree from cvs? (I Vernon> noticed that the lvm is built in the "stock" xfs kernel, but I Vernon> think it was 0.8 final.) Our prerelease is based upon a 2.4.0 kernel, however, I think our boot disk is still a test11 kernel. Russell/Eric, can you confirm this? In that case our boot disk has LVM 0.8final, while the installed kernel will be LVM 0.9. This shouldn't be a problem, as long as you use liblvm 0.8 for the installer work and put 0.9.1beta userland on the machine. A snapshot of LVM 0.9 was submitted Linus and applied to test12. This submission was not endorsed by the LVM development team and there are several issues with it. An official 0.9.1beta3 release just got out. I'm waiting for that to appear in the kernel before I start doing surgery to our tree. Most notably the XFS userland utilities (mkfs) will have to be updated to talk the 0.9 IOP protocol to extract stripe size etc. (You can always do that by hand, though). So, to be quite honest: The state of LVM in 2.4.0 is a mess. If I we're you I'd hold off for a week or two until the developers finish up a proper release. Otherwise grab 0.9.1beta tarball from sistina.com and apply that to an XFS prerelease source tree. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Moving Forward. From owner-linux-xfs@oss.sgi.com Fri Jan 26 07:04:34 2001 Received: by oss.sgi.com id ; Fri, 26 Jan 2001 07:04:25 -0800 Received: from mail15.jump.net ([206.196.91.15]:46333 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Fri, 26 Jan 2001 07:03:57 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f0QF3YI07070; Fri, 26 Jan 2001 09:03:34 -0600 (CST) Message-ID: <3A7191CD.43350755@sgi.com> Date: Fri, 26 Jan 2001 09:03:41 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: Vernon McPherron , linux-xfs@oss.sgi.com Subject: Re: RH7.0 + XFS cd References: <3A70A039.9070400@xnote.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing "Martin K. Petersen" wrote: > Our prerelease is based upon a 2.4.0 kernel, however, I think our boot > disk is still a test11 kernel. Russell/Eric, can you confirm this? That is correct - there was some strange behavior with the anaconda installer and the 2.4.0 (released) kernel. Although the installer _installs_ 2.4.0, it _runs_ test11 during the install. From owner-linux-xfs@oss.sgi.com Fri Jan 26 13:31:27 2001 Received: by oss.sgi.com id ; Fri, 26 Jan 2001 13:31:08 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:11352 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 26 Jan 2001 13:30:41 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA29383 for ; Fri, 26 Jan 2001 13:29:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA605577 for ; Fri, 26 Jan 2001 15:29:25 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA54856 for ; Fri, 26 Jan 2001 15:29:24 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0QLUg815933; Fri, 26 Jan 2001 15:30:42 -0600 Message-Id: <200101262130.f0QLUg815933@jen.americas.sgi.com> Date: Fri, 26 Jan 2001 15:30:42 -0600 Subject: TAKE - reinstate falling back from kiobufs to buffer heads To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Chait pointed out that I had inadvertantly changed the logic in here so that a non-implemented kiobuf I/O path could no longer fall back to using buffer heads - reinstate this logic. Date: Fri Jan 26 13:28:52 PST 2001 Workarea: 128.162.184.86:/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:83292a linux/fs/pagebuf/page_buf.c - 1.49 - Fix pagebuf_segment_apply so kiobuf path falls back to buffer heads From owner-linux-xfs@oss.sgi.com Sat Jan 27 13:42:23 2001 Received: by oss.sgi.com id ; Sat, 27 Jan 2001 13:42:13 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:43311 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 27 Jan 2001 13:42:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA17782 for ; Sat, 27 Jan 2001 13:41:03 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA40268; Sun, 28 Jan 2001 08:40:39 +1100 (EST) Date: Sun, 28 Jan 2001 08:40:39 +1100 (EST) From: Nathan Scott Message-Id: <200101272140.IAA40268@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: tduffy@engr.sgi.com, tes@sgi.com Subject: TAKE - acl.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:83345a Date: Sat Jan 27 13:40:40 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/libacl/acl.c - 1.2 - correct the cpp logic for syscall expansion. From owner-linux-xfs@oss.sgi.com Sat Jan 27 18:44:44 2001 Received: by oss.sgi.com id ; Sat, 27 Jan 2001 18:44:34 -0800 Received: from main.braxis.co.uk ([212.160.232.26]:24581 "EHLO main.braxis.co.uk") by oss.sgi.com with ESMTP id ; Sat, 27 Jan 2001 18:44:12 -0800 Received: (from kszysiu@localhost) by main.braxis.co.uk (8.9.3/8.9.3) id DAA26116; Sun, 28 Jan 2001 03:43:25 +0100 Date: Sun, 28 Jan 2001 03:43:25 +0100 From: sooo lame To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: damaged drive, kernel panics, yet again... Message-ID: <20010128034325.A20166@main.braxis.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Steve, i had no time till today to do something about that damaged(?) drive... here are my results i set a little PC - AMD K6-2 266 / i430TX (PIIX4E) with linux for diagnostic purposes RH6.2 modutils-2.4.2 util-linux-2.10o e2fsprogs-1.19 (that's what i changed) i compiled CVS snapshot of xfs tree 27.01.2001 21:52 CET page_buf.c 1.49 and i mounted damaged drive (Samsung SV4084D) onto /temp then i executed $ find /temp | xargs -l1 ~/script > ~/list script looks: --- script --- echo "$*" echo \"$*\" | xargs -l1 cat > /dev/null 2>&1 -------------- and tail'ed -f ~/list on other virtual console... after few files i got: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdb: dma_intr: error=0x40 { UncorrectableError }, LBAsect=2046479, sector=2046416 end_request: I/O error, dev 03:41 (hdb), sector 2046416 end_pg_buffer_io_async not uptodate 0 page 0xc0017ad8 kernel BUG at page_buf_io.c:923! invalid operand: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010096 eax: 00000021 ebx: c0017ad8 ecx: 00000001 edx: 00000001 esi: c0cf4bc0 edi: 00000008 ebp: 00000000 esp: c02bbea4 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02bb000) Stack: c0269f5b c026a0dd 0000039b c0cf4bc0 c03328c0 00000008 00000000 c01eba04 c0cf4bc0 00000000 c03328c0 00000046 c031a2e0 00000040 00000008 c0202704 c03328c0 00000000 c031124c c02b4c60 c0311164 00000008 c020948d 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c eb 19 90 66 81 7e 08 00 10 75 09 c7 43 44 ff Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing i see the way i can save files on non-damaged area (by lookin' at the list and 'smart' excluding files that didn't get on the list...) the problems are file related (not inode-) (you asked about it) will XFS ever be able to deal with such thing? (or maybe it's not XFS fault at all) best regards - Krzysztof PS yet again, sorry for my terrible english (don't be suggested by .co.uk MX ... it's only MX... ;-) From owner-linux-xfs@oss.sgi.com Sun Jan 28 05:26:18 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 05:25:58 -0800 Received: from porgy.srv.nld.sonera.net ([195.66.15.137]:10842 "EHLO porgy.srv.nld.sonera.net") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 05:25:25 -0800 Received: from qn-213-73-144-89.quicknet.nl ([213.73.144.89]:62017 "EHLO auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id ; Sun, 28 Jan 2001 14:25:07 +0100 Message-Id: <4.3.2.7.2.20010128141834.037976b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Jan 2001 14:22:36 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: XFS prerelease announcement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Russel, The announcement made it on http://linuxtoday.com/ What's next slashdot ? (mwuhaha - evil laugh) Expect heavy traffic ;-) Good work -- Seth Has anybody seen my lightbulb? I _really_ need some light here. From owner-linux-xfs@oss.sgi.com Sun Jan 28 11:57:33 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 11:57:23 -0800 Received: from [200.222.192.138] ([200.222.192.138]:65171 "EHLO pervalidus.dyndns.org") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 11:57:03 -0800 Received: from pervalidus by pervalidus.dyndns.org with local (Exim 3.22 #1) id 14MxwU-0002As-00 for linux-xfs@oss.sgi.com; Sun, 28 Jan 2001 17:56:54 -0200 Date: Sun, 28 Jan 2001 17:56:54 -0200 From: =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <0@pervalidus.net> To: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement Message-ID: <20010128175654.C6620@pervalidus> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.14i X-Mailer: Mutt/1.3.14i - Linux 2.4.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Mos wrote: > Expect heavy traffic ;-) OK, so before any /. DoS, could I ask why the XFS patch is so big? Loading it on my machine was funny (24169590 bytes). There are RedHat patches (anaconda?) and others included. So, what's really added/modified and gets used by /usr/src/linux/linux-2.4.0 or whatever. And can we expect a small patch for a future release? TIA. -- 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR) From owner-linux-xfs@oss.sgi.com Sun Jan 28 12:11:53 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 12:11:44 -0800 Received: from web10011.mail.yahoo.com ([216.136.172.122]:47116 "HELO web10011.mail.yahoo.com") by oss.sgi.com with SMTP id ; Sun, 28 Jan 2001 12:11:30 -0800 Message-ID: <20010128201125.93490.qmail@web10011.mail.yahoo.com> Received: from [212.75.66.79] by web10011.mail.yahoo.com; Sun, 28 Jan 2001 12:11:25 PST Date: Sun, 28 Jan 2001 12:11:25 -0800 (PST) From: Magnus Roth Subject: Bug: XFS prerealese for linux 2.4. To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-650579519-980712685=:92933" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing --0-650579519-980712685=:92933 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello! When i use bonnie++(1.00g) on /mnt/space and using X(XMMS playing, and also starting other applications) at the same time, there is a total lookup(reset is only way to restart) after a while(memory problem?). I use the /mnt/space partitions that i have partioned using mkfs -t xfs -l internal,size=8000b -d /name=/dev/hda16 The file bonnie writes stays at 120mb. I added as much info about my system as possible, all is included in the attached archive. If you want more info i will gladly be of assistance. bye Magnus __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ --0-650579519-980712685=:92933 Content-Type: application/x-tar; name="xfs24pre.tar.gz" Content-Transfer-Encoding: base64 Content-Description: xfs24pre.tar.gz Content-Disposition: attachment; filename="xfs24pre.tar.gz" H4sIAEx7dDoCA+w9a3PbOJL5av4KXOXDxbVjmXiSTNVUne04iTd24ovizFRN pVQUCdlcS6SGpBx7fv11A3xJoq1kb+3M7IpJKBGNRjca3Y0G0GJuJ8X+s0e+ XFe4nifh03U9JZY+q+uZ6zEuXU/Cv2cupUy6z4h89gTXoijDnJBnaVaG0+v7 622C/0WvWxj/G51Pk3RxOyhvy0cZf+q6amXcO+NPqeTN+FPUBcqV8J4Rdzv+ j359fKsGzHH29shnnRdJlhYkSUEk06mOX5IXyYQU2UyTSaKncUHCXBM9m5d3 JMvJNMuuEXGRLopFOCXllU7JPCuKZDy9I3fZglyFN5qAdkH1aYxfDIFd5xS1 jdwSNhADd+/X10PynJHhIiV/D1PCfEKDl1y+5B45Ov5EGGgISaSvgNB1mn1N nXc6T/WUzLJ4MdUFqS/TmvMmXZAjsnbpy6jYY4OADpQydc7Ca71Shw88f0Cd Q+CuTKbFChSQB3LgDhir+D8ip8k4D6F3TQ064M6ruzScJREBk7rWeYM+jWPy 4s37CygfR7tV3fM8i+bFGrMMyCjnLFukJekBUjd33utyr8yyVS7pQArnCISc TfUq3B1wIDm82uvvnQsErUBPszDWcQOazRcChqAAdmIY/QV1r6unKAN98CkP gBJJp8UoKTLfl8EeNU/RXMAY3kzCksA/59n2+nP6/2tjT2CejzQBdP2/meuX P13qeY3/dyVD/0/ZU/v/PMse7Psm+F/0sq6scs0dh/wC+/s/u+TFZRQ14K4T BScdBC6nYt828cIAKbg1RnI91WGhd3c3+fWtT/gz2H80XyTpJHus8G+j/Ush a/t3uUuhPpNQfWv/T3DNIQLRRZHlOy+J69zoNM7yURLD08ECA7oyiQ7OXjmg IjCHz5LpHUCkA6GXnu7A18B+JRDyaMQ5e7X3Tr0oZ7uEv/obOa8bd4pSz+dJ egl1qGns7O0fiC8kHbhUOFEYXWlSJH9gKzD65N2hM4mTm9F4gThp5lxNS/Ng nyauO2lhUTYL26fJfIG17nSBX0f6NtLzEtxXVYbaHpOpvoEeIDdf503taXhZ 4AOgkRuIemNN5oUmZRGRWZGTWaRJdOuT+aUms9ktKe6KCAJlwmMIS8m1Gs3K PHfG2WU2S+YFSscFfwjR9Z/c/qtA+ofZvxKqtn+oKYz9e1v7f5KrCu5XL+oH MF/DmoG8CBdlFsF8nkIwgEs9He86di2wdkmPB2wN6zdL44tTrx1WLiE9Q4s5 7aJiZWGmAgUfHvltaRHyxanXHqvcS6qwRdrlw1leoHSWPr7Aynytsl2/rDDL JVurbJY46xelnhBrlfvrEg5RsFqXHTb9xXlc+0+yeZaXP8z+IdZX7fzPJdq/ 4nRr/09x4QDswRhMyEsSz0LquC7DAo4F8yTCAoEFEgvKZKZzKFFYorDkWt+N szCPodDDQg8L8zKCZx+f/aphMg9h1sz1JQBCBIwrAgwKIiyIq5pYMMGCCRbA VOzAAhGewT7gOYk1sESxAp1UBa4DagMFnFMosN4Gijy1h7cGiSMZbsjcXIZ/ g4IJ1pioppVo4u/BDWucH52QKEsn1JERCERGRiAHkc7JaTjO8rDM8kQX5CSN BuS3g9PkCzmD2YuS87MLJxQgVLhtRpGMBeTk1bFDSI3UdMoU+XU7pg+hj3V8 w+FHHU5LfU2GepYAp/EigvbJUTb4iZyW8YB8/HS6h/4R2+mg6fLKdcY46mMr 4YM4nJc6IgdvD/Y8XwIQGRlbRo5yHZbJjcYeFGR4SE7h4b+cMTY49o3W9Fch x2cXFJULyHdrm+J31ImRg3jSyPpwUZDnMGyExFg7tszyV5NbkFep8zBCGj9Z 4X3Oshi8Pt8uH/9F/n+mZ4/m/Tf7f+F6rf8XeP7DGN/u/zyZ/6/mADeYWHsc 3sFybUY+HpyBKwZvXYHHFfgzuKIMoXgcEGKVqK4SeUtVPpgGJjV0stK+AdOK PIDGa+QhHGoquMwH9zSGCtX+fwQrT1PDACKsMVHUuK2qRhyWwB+0GtUktCVx cHR+Qj6FY1j1GPikhk868PdZuneTTcG5TTUZgnOFGcyJI9/yY798ryfuQzce OY6rcTBfJv2eOY5rbPxSVdowv0AEezE8RNI9yItivJddRYkD800FbIWw4pZ7 amxyz7pWLs1b0T7IL5WCOlpOKjTvHma0ctdqbGKmGmZ3b9J2INeFzm907PxH +3/w/j9y/4+6QjT+X7om/pdyu/5/kqtefpZ4vP0Sv+EK33yZ5FrDl+IK3DyU jBfgPvMCSsxmXfzSOdMzeGLgc6kHBkmY9IWgjMIylklPcV80R49QEgjpMkGo r1w/EB5zhl/D+UsCftHzfeb7bd2mCCl8ahjDpboUARC6PkTIa8tfs4yHRX8F GVYsd84+EXLY9KBd+nsG58j2qLP9QXFPAiAHxpd0UVyuTGsnKfiZUZzk5Z0B Uy4CylqIWcFbRBZw3oGAwl3qsmrT801rb5PLq6WuNlwjZKWrFeQ0+3qPdABy j3RQ6F0kypW0XCOki9RCtlHyv7f/L2Dkix8X/7uUs9b/e8zE/8rd+v+nuF5D cGsOb3Z2Pt3N4WOIZzAXMAfsnOcJBGjlnbMf65v9qzhUpP+ah3mZmBMW6zN2 3J297dHuX8j+p+H4MQPADfbvKdWe/+LGL+4Ic7W1/6e46rEne3WWB4RkA+pc w6JgZE9lO5fHq5jFBAgQa2Bk0dwAq4TFlx7pbt6aoOYQpPqgJgaEGMreulhX cb6OxZiswi4TxNQ3wALNHUVXYXE1TYqGHGPmZIdzv8Va4hCxkmmyfPTiB1iP B9Q2jZSpkNWtwZpk+fWy43O7H1I1390WS0+SUYLbGatYlhbMcy1CFyv+J7Ag Ql/FEnag7IdkDYJoseIQ8Hr6xVxmSao+WnE4AsMp9T3S4MLtk8ZlOF+dPJZk SHtlCOqRruY5mpsdXs4a5mgHK0mzuMseaBRtFYtIPPSTeFxpbo0MSwiBR9Ei X+WQWZ0X/ZKfhfMRrpc68t8gxDKaj8qvMGbRtS7vEUewJg7EAnuNl/Go7QC1 1snbYe7QyuY6HeX694VurGWJlhKrtJJUl6O51vmyH9iEBYJIxiM0zO54uQ9z CFhxUa45nC4tqtZUKszn6z5qBcuOWxdrPL2GgKaWRVHxx6x3kh0sLusbYMVp ViaTO7JCb0kabI3DCe4dTrPoehnPKoWwH8GaNCZhcZdGpFca92vUIon7pEEf lnxxjQv70ZUOu9ie11HASvKi4zgK7NLaeTe3bVqR+WZ6YF59Ayw8AzReqlw+ rW+8bkPLNKRWsHJ92cHkD/crvJmOsvE/NK631xzig1gwe+V3yywqO7eoVSxW Wwq4mhXZq8D3zIcdXgHLfOJ7oroZPUQtXBsw4Vm7Cjr2xQzPleSTS9Dbhe51 oyywA8BWdeM6yda8PMq849NoRw+r8YqtKJZ4pDBvmx0S3rEU41lVRSv+fZH1 pDhs8GxgKWtzA0xcnvnwO1hLGoVLl2JdiBUtrCTcDq0Ky25lGZ1vYwABmkeV 76mGFqiJB0ZKrVCd2QymvHwRLffNqi0Rfkd7uwHHzWyExyRLqDQwMzIN7GDb Uea8vqE0ij5TFlZtZVc3lvwGeJt1xArLxjLC+g3Z3IxGpeF0FC53TKi2X5iP XbscqmqsP/QeACBwf/Hq7GB3dZQtaGmUOeti9YwXXcWiHSwlJVddUh2NMrAl WlR1sMiaLZuPBtbcaizOPOXfQ8vAlrXX72Ct+16jCg2s9RsVFsWN0nto0XoT taUlOljLylHlYHWwRDPKFZYPRr5EqmuVfuUBWlqsxSL39KvBavtVYaHh3Utr ySrdjkbVgJZU0IZfFdAUVfGYxWKu8O+lhcBeWjWgvfw2nKqBojMTWclDqHAv rSqOWKdVAzqLDjtqbjf66ISwBkvSleFa8qKSsl5aVXknL8/S8rtY/iotJtUD tJjsH6+qfHX+Ip7sYIklb4PSYP4DtHpithpruVt2hKTXwTK6UXts6wFWRmtj BFthrcyUzMx6wvbLYi0tRysP8CAt3j9efGW4fCVtGNWJN6xuVHPKv3j/Zx4l j7j7u3H/B2bY9vxPmfwPCl+2+z9PceG5OsShSaQLMsHk2pcOMQftxP2pAhDz fbJII9zjhQesQsjbDBaS4zyJL/W3nOqTF7m+IWJ34FglPwuLEnCOwjmmYQwI YJc6je5+VgIeqkqYgjHP9USX0RVWQ1sYJyWZ6VmW35GwJO5tnWRAfoPvVZ7B l0FfL2hPL7D/39YJySCQ+q5OnCUpeZOWP/u93LAebi6Gh+Qog6A7m051/q3J HZYr3nB18vF/wVV8I4/hLRb87LuD75B5nUuCMq/TSfplznt6efhN8q6zKW3v 3N3e5r2e5k+GB9+slxBvowaUmcGyjAF0GsYxDN7J5y+WOg1kP/2gh/7ZYop5 snESknARJxnmkTYjuiFbclXBzFC6G4eSs466sUE9qKzBPNn/YEcOczFx1DAd 88vmLtFKpOl8UdZVvqE7Vmi738b3GouiYlG4Xi+LtM8dDY+GJ6SwWVpLLK5m Ua0yhyKW3ydh0UhYrAu4MgvMrv3yfTbldmzKvd+maJ9NHZdXmPNWLnX9WxPT KpGo/5fa8Vbv1LpYwkrvMAv5+8QSdVxNlTTXLxbZ5wteHZMEc8ImYaS/NRm7 tnm++88aXk//K6XGbO6Wfbphjv385gAGdDYHG0PxdMd2Q7pbn5ZT+l2C1x19 nHTmVTNtbpqUVWdS9laQG6HElVLEVim2p7E/5vzXnN9nafGDzn8ZY23+t/Ls +a+3/f3Pk1yz8B8wJcySFO7k+RiPKsAv4baqMdUcwpd8pnP87U6ho5Lki0KT r1D61ZZ+NaVfsTRfpGmSXmICIQlv9O+OU+/S260Rqhj1uCJXcUhgsLmPrwDw XE4UVwLmZebB3cXdXh/uvuSuABD3oExy6ioXmmGuxO1q35Wectv2aXWG4+Mm ALRPCQsYVg84kYhX/5H4t8Vj3S0twGPE7fvTIshqkwNfUYEIEvMBYerxAgLL dUGEwA5AZaYMKj7Dv7YB1eTWMdOAAsLQHzw6av8w/Nvi2F1rxX0ZmN55eHYO VCRTHoN5ijKQlO8phoIBoPKIpxS2ATE0NKd8Hhi58q7M6hNyHyIAbNXH0y+f eIgDMQFEBZRSkJeSghHpK6DBFaZm4s8xAzMaXEigyX1cr7cNBysNQ0OwTqF2 vAWwB7g+sIgswXOALVFD1euMDXVXmqGmCxRPVLCPVCrQGGgKM09BBjAIIB3M PjVdpqhDIuiI3h6gEE45s0oIBQIcDrQKWIIwSn1UrQCVENZ6EhpTuBnNpIfK 5zEprTQZw5MCkG6ncatJQFZ4ZlyhgOHuFwfhAxkJdADNN9JCxoiQyicSMzZx wAUDkOepLr/cbt770qsEwHHTE5Uad/LaPz7+bdHsxpUyl0HDfAsUMX1Iyahc RZP4M1rfqKok3AUbJYEHgxZgZ0WlsYEX2FvbkKoyRdyA2YbwVSEcG3KhIQpL KYgXRADeHpqCkeC86g+U+XgX3N2GAk+a/48vmnrEBNCNv//n7fzvSZP/L5Tc zv9PcZncTuwb2Sf6tmQk/2pmvH18MQixd3Ory6tcUEn2x4i1hFPBArJvzyBB uVZhlOzP0nJ/EpbgF8zv5lcr8KYG+IneGqJTQ/dXkbZKkZS6mMPSr5dP4MDW MjX6mAVuy9m8F9kj+4si72/XJfs34TIszVJNTIV5WeCiDz9W8Hyyf4Uv2+tw 8iT2b46NzY/uHscJbMz/Vqx9/4c073/c2v8TXZi5crOD6TyTwqkermbVt3ky 100xegFnB3Xa2UmKLIAwroLg+yqaaosC81rgcee2KbPq7uzcbF8D+KfM/y7D 8jEPADfZPwQAjf1D0IzzP8QBW/t/iguT6zAzzHc5LJ+YgLidwGoWJlCfBFTg KsZTuBTwJaz/uODbly7829k//HtUF7Ax/le0tX9l9v8UY1v7f4oL5nOdlqNw OoUYn6sAjdws+CVuY+F7WJ1wXBIGy/mAeMJTcMeUVt8VAjOpR7NwTpQnYIHv +0oRDzdXqm+wwvc5LO4IkxLaGc+goXpHLU5y3A5iApO6KOEB5/jjjcCxyf5c +AFhyoMmPBl4TnKJP18AD6U8H3fWfMxicokAXnHPy3Wm2SU2gttBCpuiAGOM 4G9ynfmiuBqFyZRwzwduXNxGYYyTQAB5eGIBtsiBq9sCyJe4lYdPEINTH3sB eMKTTliWedOB32dru4RJNF2YcyLP94lEEUCQ5NxgDFTg7w484iuQqlIApgqT kLnJcBUCyHH86S5wMI/wZyeBwPQzkL5P3QA8L6yIA59Kz3Mew/5/n/3I/B/8 AWhj/9y+/x+etvb/FBemHu64+Gc7r/+nzv8DfNFZcvm49i/us39wjKzO/1Pc pcb+wYdv7f8prufOc3zTbzYLywRfZntHLnWqYRLUMRnfkRn+LwkznS6sirwk cZb+d0l0nJTOc+fow/vXJ29Gv/rq57v64WR4AA/PSfU4PLwYkqQgaVaSQpd1 rYuTVxSRHKR/hD/UAwYW+Gtz+2ZekplX9hYtkeNfz48/npwdv/90cFoj4n9U YDIQ7BtsSbGY45ssW6SzD68uTo+HXYag6PPxx+HJh/d9fL0DcN168/ZiUt7N NQnTmEw0cqkLy3bVIIeIpNNSCxD3AeQDgE/Do3thZ2e/9sPUfQ0C4PWvw4/9 wHMQ5snFmeiRw9k7tSS0d15/E0cfL4Yfjvthv5y8P3p7cn6kHgSzB6H8VQ9z oG+jX85Hv3z4+G44+vCu1T0EnLz/fHr+Zrns6Oz816O3K4WHw18OzpeLzj+c H7xaa/GUjo4Ojt4ej4ZvT15/+ll2YQenJ2/eo1KOqFrGgnFcLrgYHo/Ozz9+ GEFTR++GF2ddAX/6AI0f/h97z9rbto7s55NfIeSgQHqRnvr9WKAfaImy2egV UX7tF8FJlMS3jh3Yzml7f/2dIWVbkkmmH7oLLO7t7kFrzpAcDoczQ3I0JGpe MDsO7dBRsxmb9jUzLMYewVpTMDEIR2w48mmJjLyoNVQ2l0M7GrBPklFK/bFH ElhdKqFK4rikG/xIS/Y4SllIIlZaDGLZDYV+WmHB2+tpqQc0KbY9YXyqWuCR zYpo8DMdhgMWciUlEuywmNqJujEAk2B+mmkswubKJbKFcllA/LJmohiCql5l 6vJRmETeeKih3LcZUdDM53wCi/JEy4A7KYilTTlPiV2kElDtxDv9vrHDmKbU c4tUy0ISjlUMGrDA9RMB/fJSKZTtlMt8BqvmiBj5JwTMyFf4FZXEFn6msA6R EFhlccrHHHSbSuoR0wlTGpCBR0vt4UJJmVMtdRiPPDJPBx4Jbqp9xokN9i4d +olyDhCFeF44BaWUcC1KTImHZgnUQzgF6kPXPRN6X8bWJdn983oDe92flpMH 7V/5ifOxZI8S56x6tNjii04rC81jwUyexIXEURgn5xVXb0/C8kWrxU9LOgFv 4B2AbT4tvSiISvZf/hb1B+Lb5/wDg1ONgXeTOnSSuk6RpYfSmaMWaRIzjRLE mnZ0mzrECLYZyLgBBzt3iI3BLQpZzhG8MCwM91AaDBwQ3LPWMEumqTcWsCQ+ ny8RQv4pDw3Np8u6iglocpwMb+KXp9wxdqIB+07qsYCSWAfF/momYN0EbBtp giEo4VAutFHq8jOuBNn++2b7DWPMztzDiNg3tKhhxe/U94s2HmwEjLhg3uPk rCgvQCJLhS7zEloyX8dCwB1o1LBEUDnAAZsVFk3FerEoBTuaMJtwtWoBBOJM SGBTYDZoVxrr0GAxqqw/8IZFLCrKrCwbxuolBgpCLUZIe0rtQAnk8yC1w/CG 0fPptCwW/QMn9XG5EtHVFe1SHEXgQjNBkMQwrbqRAs7tmI6pAc6iBBU/N6DY oR8RZIQ9Iiz4JUx3ShxfgzhRe783oyTR8JMkurZmGnziqXniwKxQtfwMQJUO NQ5lQ71yPRIN1ABPvWNBuXAYbLbUJFD4W0PdlAQmqcaGXVgZAkWLMZqmLthe KAFE70z6bjccdeln2N49LpZbSyRVANVSFDxshoO7fq6gk2yVvT5v1j8trjCm IxiZ2oQhJGWzr2cNwix+Buv22Xf9z7HnnW9lAXgwqvDPa6wgbAH8HbH37Kys fKaER05qsqgSxWAKoTL4RyW3KC+S6kt4NWb7l6NPwF0L419CdcdfWcLHv4TL Bv4v4flklvxi97djEiTjX2uWUzIkya9xYGq24aBsfBoz4hmxEjYJ3+vN5uYZ tZU+GQBA0N4dCqy4KJq/hyW+1TKO1nc6rdovoIAnPxJW0Nyl8EmNKPE/8fs7 M2fk3vEk6LiL4yMCuw4W3567hDizPqnuOA9Q8PIHIYlVy+tUMSXjJNS1XF12 eZUpU480RwnoNHViUMvg/PGEBUNu5Auhdqcx01geCUsTcGaCoYF3xGP19qxZ JHjq2Idic/++023V+ur+JSwNwcbE7ykyIS8zM8q817A7fTNBNm+3m2bRHEVJ U9OVBIlphcl4t5VOx4gSMabuBgGKaTlrIOC9bqtu9tTDKGGdRt1MiGM3ajox OQDTwTjWuLPHvvigZUTgDNhfN88Q9+x+jb7DuiT2G33zNE4YAXmYaUYF8pbi CSWnCdev4Xz9Vhchm6hdKbFAwwA/STZqImFY+cEfkJ++Vh0GLFUpHq7WlfYo luDECA45Twy08Vi1C+axwsAfyIxTOgO/HhH5l8ZFlZxhsUEck9xtSVdfrbsE lnRAvHGgR4F/84TojmYEihcOh5VFdGL5avP9k7yteNguMXtm0Qk8jL05TUGE ZmJLrO+nC8YHXFoN8wUKsSvWogIekXq7MXsHodUwI3RbKhsowczuwkCK05EX pYl9m4ZBOpjDiF0CjFedvOW4oId5GolN84TZ9EuviiB2/zAvSeEM9QCLKcdN BfXI/Eu7Sj7uh/ncMJksaFRsfKUFv920+92WQajokJgncjDmIDPMNkhddOva Jplz/Fmz3q8bOnESu4kfDGkRKO4OjNBUZ35OGBEL9RjuOBmD4+OEPuyS9WhD JxkZoDQAn9ZOAztuN03jATVrmlaWmEgFOKmb5l10b7dqHfIeTvfHj/dQejPD GuRz/z2UiPB6xwC2mVmIEaHRqDEDBmeNlgnhVkgwbrHfxWE8er8d+12UulGa c6SGcRJNey2JwDClyHtz0zIx37Gb/ZpBRSf4+akWOq630mbLNSB4YAe5biN6 sn1n1ohRSvGbzZZ15S632RT++6g65Uc8gXbWQCO0yqfNpWoN9eqC8rTiqpRg Ay/UndYB1COBFqbdIIouwUDozobPR3E6ypEG5+g1kdjGfBmnM5PCUWf13Ozg no19f17yqcLA0fnY9HYMG5x/as6wEo1jQpMRjWGnrT3W4oPqRlWQfsz/cQUy vtnip7X+3XL/scQB2XrlrBnLpXeWNu1QcyqPe2wtSXlt7tvvocTgxHiaU8x6 V7O8caOtuQCNdCpBnGVzojn5PrsEhsKm2jMiDokSKhyS2GW6s3EwxxpCSAQG LtT41LzX/1HTiIen2cY7tDVTb9icYcw1u4p+vaYeHqWwmnRMPADTSCMVAW1q 9lABuG/UZ5q5adxo9QY02dBoacqroByAKWySMCx6pnHi9eoN9bEB7CH7uhFH zNZamXHgaJdBotNmsIlM4xHTnAdPWYAqJO1pDrtGJIrmPtWsGSHKId5zGdUB jOegCgoSSwONkzoiPoGNrRI2p3id7eo8vpt+z9PAXMdhmqCSKFJDokjjW1SW hhgX2rxVtttZOBFX68360/PiZbt4WG4+Vk/0Y+KU3UV5or/5lq2tGC8XFSYh MdxEqNkY2+pdPIc5pbhLlmQv1qf8RKUep2WBkibrZbHP3rZWjONSWWqYO/Xo 2NYh1tVy/bjFl7HUzkFcvhmX9bgTAPKd/Dy0hI6QKnq4erBs51MMZiTfEuNc 7MV2+VqgMoeWJsR20iBUnQnL7kXeMfEi+PmFSBCNy5emWJDe0PkALL3qSEbA /XDMaelyt1wOvkdMaZDOvmBotBln/qXb6VUJ+BrOTf3TiexcMuF5gembsu35 1c2kcJk9ScRZRVgMTuHiNqB0OCJK8DQFjK3mRDzHCeTJh6M+f8a76X4vjZJ5 YQt+KgRaxkHypdHuHJxHW+01nntpPoyxdEgy5oKn6jiCKkTU/LoBUVzefyst FuA5T5jG2bxldq2RVm8v8uW3v39+2DxZ9mL7UGD+lCT2yAmHpRPrvAyYNyVz dbwTD93kVPmleNytuel0Ep0ljOxDQxqf43YM/oi25U5tNtMCfTYDV09z5cR6 9Vqa2BqfP0iol8YanzeYVAJejubYLrLSSTQ31nGz32lp/KjIYxX3VEyhu1+8 ZtcW2DvrcbV5ff1pYcFhHyC1UFFU3KogHDoYRqXwrmEkx6qmBqE9jZ+CwAkj WhjRxOMgDHwTNW14WXJajE7sl36kieOWTuawbEh8zRkPQmPdXhWB2rEh0B8S dcCSzHmpsJ4T0O9hWtGKcvbwfYw898Bp+d2Ow6R0vYXH6C6vxASVYC0Almo4 Z/hVWBpP1WBXX3WkBw10BLokQeKOYY0+d0IuS46Vx4dCRf3JsYGTn6on46uB ehtWpwZ0Bjma+RC/9JfcPWpbjxVjrXwGtqFCYZDoyRAwDfNHkY6NeVRYSY/Q ib4XCfTRVhngZwcqJ2iU8Ep/t8Gspe8wh2oGBj6RbmRgsRuVnjBKV9dPDkun MUtUmmzsuFXpghINWWP9eCRI201EhhQMeCGId+ZWGYYljk80Dj5CxVJXxfgf 5qbc/CTAOFkMA2NBBcTHEYawHlyrw4GQ0DC8qmHs0CGlRRm41SWJJZOmZi7D BOFq6XY1N2wIqLR42lrGUSHwGc/NnNNP7g8qtGFJ4HHVdcupOzvSLkAbV1ke IsnZUHtPLBFZaCeeIMqMhxFZRgRkaWAiKeQNMwL3iec5oQkF+GKAirtGrgqQ lk9YWvgK5q4SGp3gBUNwjLhUfdog1PcRteCmy5kqhJJ6xxPI4JA6ef30hlmL +dmh5WmKv1wud5ter93/VL8sgvG7ELESW81uQZqLkK4e0m1rIL12TQtpaCH6 1nQU9Drafjp1LURLQaephbS0EC3VnY4W0tdBurp++s2GFqLrp9/S9dOvzg/Y aZSOtK4ubqiLm+rilrq4rS7uqIu76uKeurivGY6GlHqFlpuQ9dK4XDZO3N7h nMXerHebVVa4qD84V0NS2FtXPFZOvcqHP4Ug92O9c6d2u3jJPslHplQ7Y3dw Hk+ATy8UYjfAayl9TyAK8Ds29ZmSgIoc8jf182rumFc+yKq2y1uNXt2AQHm9 2a29h2BugQOvQhOKTyhaEAMGDwNmT9hAF/chkBIMBdP4fHlHPHBsj/B3UCJm 4pkyOqiEEfKCf3GgjdgU76sLBkIAHPmdQqUP4tR7uvtIyZAh8chsbsAgjscG JrjN8DRAc0t1Eg/N9UhOBrd1saESYTg2MZvZIy0TJz5z2LlIwyTPjNPHtS36 0bhVU6ySwMd8rSbxdIxzEWkECsrN51N5dW5iETfO4ZQ2G/iphS7WQmBNyYS6 4KAZVwYZMwN47jd7dZMghJHX5KT+LkbD2InuROwAd80IY/DCOvjQg4Fj1OGR cTaTydmqEIoan1s5O4qGwuLihZ/afaWE4UV0eaeE5QMSOFOmi5hBjPFIM/ID MCXK4CsEh6PyrSeWkbGjiZwR9HhjmsBWR08PBisQzXckon3b18KiGM/XYg21 I+ZUiZ0S3fW0YKqtiz9FqO/YPc29nhiHTYJAowNFdfwEO6E3WgQ28G2iJy6c tOt1Pel8oO/aIYOxZvULLnpGKB0SrtG9CA9oIh7X1IoU591GTbkIeLZdLlbo WIFDtVc7OoK1+q8WEByzsK0IZ7jB28uV9by4/ya/yTl+Y46RQHzORcD96XMq R82DG9gt8rmvZoAbEx+/uT0Tw/9r+V8eHv+l6Z/ey/9Ub9dO+Z/aMv8L/vX/ +V/+DX/cY+7f4muH3z4dXoIQr5LtsgeL/L1YrkSyFfj5wfIxZzgUb9antMeV Zww7tV5XPnrZ6MP/5DOSvVYP3yZt1z9YnwvJpCt/mrjJO7wOnb8o2Ww3a5hb vvVBpp4upJsu/2nUwL/Ln9buNPNnpWvdDr6/2up+yJNTFzJSV94cbnR78kXk drfZkgNotVvi4dx250Mhf3UxZ3X5md5uVz5n3WzAaDvybc9er4MPcHbbHwrp q4tJrcvM67Sb8nnLDvhc+fvHjW4dB9HvFJvIilmvy220O/mr2tBYL3/XOH+d t1b7UEmRXUyLXW6m3+vn81g7kNLq17rYdPPYTLmJClObtWY+EfJVZykKXXw2 A6j5ILJsFzJrlyekg9Gh4m3PercNDJXC0G7ju7NdnM+33baYe7siDBgNmz+6 0e7LZze7vbr4F1b+e7EtJODWSVIdyK/1cnbgUxgwQR9kuu6L/3j9P3N7Hftf mAKsmP+r2yn/Xas18a0Sof9bHZxW1P8gL//u93/A+C9W3/R478H/U/N/yQuS UtKvH4+9jkz18dfh9Oz153b59Ly3ru4/WvV+v49oyXNmzdxtlvU6mCvrv7P7 vXyETJ6oZ9uX5W6HR+rgWj1n2wyqPG0XaDWurUeoZm0erfvnxfYJr+831mL9 03rNtjuosLnbL5biLaEFtHQPvSPu/hka2m0e998XW5mOa7Hbbe6XguyHzf3b S7bei+QBlshob11hUMAlz2tcfryGxqCjhwz81uVahAwcgNb35f5587a3ttlu v12KV9iuAel+9faAdBzAq+XLcp8nKBANCLbssNm3HYwDab3GdGTLR/w7E4N7 fbtbLXfP19bDEhu/e9tD4Q4L77M11IKm8i/Rd9lqhW3gy3RixCcKr8WIoZ9X ZOw+Z5Xo+TuoIcQV54j5eIBVj2/bNXSbiVoPG2Cd6BXnCUtExMRmtdp8xwHi 84DiAmT3D2gG4+EAvLjb/J2JMcnZhzWAQRWCEJyM19Mc56Dd8wJGcJflrIO+ l8ipRWFYWxFPtgdBwP0Dbhmw1+pw/8qpGFELg2qmJKYW41YUh3g061iXhMPv y2trypIRBuMARkyCZG6FrkWCuXXDAufaorMoppxbYYyBSn7kMQqlLLC9sQjc HkDNIEwsj/ksgWaTUHSZN4ZZK6A5n8b2CH6SAfNYMsf5clkSYLtuGFvEEvc+ 9tgjsRWN4yjkFEhwoOGABS5sc4cUU4T9ZUHHUGjRCZ5P8hFsTvIhztyYUlxG cfgVT5wHFCjCTBWyAxiO7RHmX1sOgR0QUhVbIcZyC7QjVdORCPDGbgj83xZ5 uGAAIgcC/LyG8cXJsfKUcUwkEDOOrHDjEDpAVoYuhvKJZjDpBpXtIKPL8wEo +BujtI70OJR44qNiqAwFKJI5ej6j9Md99rqHpSteM4RlLmREypMUIhnMI54g y4WiomWklEFbuGEDWXvbyTYWD7gVXe5EgpittcEY2O/LXSZWzXbzstlnornd YgWd4DNlByxoC7UCVNwdiTlTDa/bJeB/3y73+ww6e4PS7fJ/coWzPS7BCrGo DaH0v37LH2gozvBWIV+/J8t91frc/mi9LNYWZnSHhY0hhcDe1Q5XMVAvl/v2 ZbFHrgrthToCFOVfv4+83zlQP8/pmMknMT99khQfC1DFiZkHXuxes3vQuFDr +/Py/tl6+Anik+ezXJWTRAqNiWW/cdh/XvCcqEtJ9eXFH5ib0rIusx976Pf0 +8eyAHzNfrRPv55WP04/HrbL04+hhyGwlxd/HqF32eUffz5s3nBc8qIJdPs3 VLOPb+snMOVgex4sJ2bHNrYZtFEgBHNa1i/Fi5yHIjTKWHx5cUHXD/mQLk5j g+ZkBR8TdsKWvlPAw/KLC2E4YGKQwTshcw7oMpFkXJgJOQfoViC+7Ff+EWMC Wv60nOKwTnUVbYPxuQeLuVhnm7fdCXOXdyNNJhhdnP4dVAefAo0OFAiKy9rl kzMkBUpx1QtVAAvmQLWFVPO3u+OQj9NrCZAVvh5YcblBI/3jUTb98LSAsQGO TJ96pEPqo1LHFwIP+XrsR8VWDFOoi/Eh9fgLVvf6QOpOTNN5raE3yzHOJkCK 38WfxZn/jatZnDMc1i5YQkEYZp3/jq8hPS7eVns5ABzS9ukO1Nj+WazVuyw/ tvtdOuooz4Kmy4vc2Vlt7ktiEQ8H1sNiv7hb7PDF32CzF5YJyF7uqhYKmkBN iu9ovkngSZCuVstv4IbiEdslGpzLvx7uLj8KFmTSUVujWgZVJSyatc6kTgPX GFayaCxn0F/iRU0rfrqLgDl/XOLG9/OsXo87n1fLO/zXZ+CcGJCIx3wFilzg KWJb4BuLB4+F74x8h16upLbEIjDG9/imsXCm95unDM2i8JjBUn9HtxT+ztUs 2teXQwf3m5eXxadd9rqQ+4dDP7B28MmrQ//CjwdMmN0rYMICf90t10eO34Ed Bp0FNvVh91F6Cux/23u2rchtbM9r8RUe85BmBarrXgUrl0U3JGHCpQ/VTUhe WC5bVXjwpWLZQOV7k184z2dfJFu+FNBZ0OfMLLxm0oUlbW1tbe2btuS5tYoz tWSuHbBEHUzxhSbQ/zL2IzwZsMwv6UXQInRcuQ3ySTq+a2p3qAa+Rwhzgxca BzFAQLUBrl9qZUuY12QFC+MWIZdX13QJ0wHmsw/yM42TFbsQNMNQqr0SWMop jQvHCBTACqEFaneLrB6atnwmYK01zBwyv3yLTBi8tZ/eAEUg1N98coPx0Fv6 b/eySEJPwvuMrsCLx6af0YLI+DkNmNqf04KH83dGoZa9vjpaOAksBZQ6vDRz qYSvcJXK6/guIkdWqy/W9dRjtT8lhiua9Bnl6VQkYOzCenAWhVh9CSHJHf2A /RDNPkUFj/skoF2HvvjLx3S8LFzix73Jzl6CfX5HUs6xpL+I0O+WuLRhMQn/ VnhaEYQO3vuNSxzbuSpZB036yMpApJL9ht+oAREM7jPW50V963sIfCZS2oJK HfcG1jJ+zk85+AVSGGLwyU/wxCxbLHBfacPU2vZp/DFxllNCdN1glTVBsL95 n6TBd9/sB+l337ybfgfTQHOCn5fHjaTfMxHhcZeSrnMDH8ARKEUEBn0jVpa4 haJ2BakD4NrfnOVnovPzh6uvv3uL/+x8hywO1AODxr2mzbQcN1lRxI3ICZjc HDvZhJ71WxyHjyGYRTqOQsjew8zBO6H6bFu/+KQkfGYdfgusFcGk+qB9kixS N7DDKOB94tGfYQymFAr/VAVWJKosZBEAdIcNlY+oVV5JsYZtVDLYJassblLw J3AW8Fgau3FgiSSJk9roeXQXvocm8aHW+WtoAdpVzxU5n3OAjycVSejXKVLp ax9HcBpHx1j7UlV+hOqmH8RBKa3hfDpZx2c1AMSbMKZFDCSFuZ7FQN8tNLtQ 18oaKmrYMOaj6EDc/q3hqhlOY7QMClNH947Km3HSWFhv3CxJoA2MJY7gP/dQ stV+iEoGgi8kho8MMsr/n370e5SAmqxfSUb5QF2ToEjyAnrD6MZmA+jIg8nz 575IWvbPCh/lgR5QWmbxGg2aH4gDwK46m7JJnS9FlAqwpNHDQovzjZ9qZU18 Z09T4GOEQtbXL9cClAgFhS75ftg3xD4YIplenPfZzLs4H7BqoeOqceAkviTz NzP42gyYBn4kKsxHbtQHhaWt3KpLulhUkSDn0iyNz8VSOOAS2Jj/0O/QIpqy ga2iGPlaOD48kHrUsCSSHQydJYAKjl4stlms4np4093aMnFq2ZdQSWpkulbP 6tuVJXMs5ikoDa5jn4jUscsVzjH4q2tghENMr/15yiYUyNNMpjAXypm9/Pld sWTRxs5gesCOT/Lh6Pi4cpyQkBJGBnQ1HRLD75HoLSE7iHsnXKJfPycXAoXJ p/YUJ7mAjS4DCX5glxkIICCmQ3IGKbdXHtjlzQxHw3NlL91up2cXjodyOT5N 8dhqEuPOA6bsZ/jxgXJ/ODWPQQ81DJuPmyNXlr28QJ0D2DZfHjsrjN4pirbV usgJ4VgLkWDUL+B6emnMVGQVGaOOFgO1KeqCYSUQtk+oVC6+gBUChIVyGz9w 5nhAEsljY/p95Vnk+SIPkO3BiziWfh7wJ7ZwnaWk22sdzIC2FGsjheV2M1X5 JzK17aZJsCfvnCVC0TY9KrIyB5W5ErlHBX1qsM/JbKcZU8Eb+zGe6doP0S6T D9LOfmh01ZUKpUr1VuRJjnirwLoR6ZbJh81It2wpuGzTKHwfh+AIQWFFlz67 pvoQ030I/1eKatNQUxw+5BPENQ12gsaJUl9Kf8Eix5fqnSZeSSHYRycfpm97 8HtTBWoTitRSQ1jH3DQnvEKLJTNlKXAP1mYiFhkoKWsp3/Ysq9yjatXSbcjW exsypE0RQkPUm9QU6n+avmuVAfy2f+/LE2e5hOWCCsoaVcb0LktT5NGWZeui HOdzAc5bhr+haa/TqZKD59f61iJlZI2soTWwxrAOzkBEBH8uwD5F8X0PSgK/ LbkjYJXV2gysIbTwrUuutW3Jv6ycoNJF3YiepwCHE9z0PwCgwxHRn2P8eRPB 4BTp78WtjpbWTIXtPKCjt1B4SzS9i1lvcYg5txHUpvCDVkLBEK3CONi03jmZ hxE0NkdIvJ/Tn7AmcntF4ufhj+OFnwogFs4oeDC8wUqmEvhoyQokqtSOGytX eR1ngWfYTFWUsHPsDVDaHeGUlUoLbLB8QugeMhf1FSegXw+qhz/LQKj2dmZU ZCjPkH0N3fSjHwokqwqnpvrPCCoGGBzHPWkw+7UMh3rDTii3KrhXMLGbS1Vn vAiHbG29v44T78T3vEDU8SdS9/UgSjQvy14DygvKxjMMZJa8Ni0TZb6ZB//j AYCBglwEfyfg6fsJ5ekBC/mkcpFdEqH4nOLUvE9veDI6LuCzslTmBgGBItqC LAKhxSZkef8RrwKApegvzai6+nDHs26+YTSsQZhbzAmGPLdYavcUjyipzdJV ie6qPV836AnEiRM11TXldVlkU58Gc6zFuoa0Tal1M/Dh62jbIRAbN8DqyDTj 4mZO5xkwaaAgF8bJ7MugksaZew3cJUTUaaILCh2q81R00nQ17TRUPvGjS7tI CbS7g26vqZpzX6427E4GzeB+Ldfrj9fAK9fr9ZuwmxIFTrNwJhK0GJvqgKOJ STbRAk1AG9tw4L9WkSVoAazb1CFIC7TTDika+Czz122YP/AGYcCd5568Xr/7 hLnrT0aTJ0xdfzKcPGHmeo3z+wIT9/E6EaDpA8/OmWb8ErP8vEkeHL99fvt+ 09qPVlZEw0TlE5Z74j2HGUaVwE4Cy81M4aCabLdu1FTI/b/GnbHdaoEJDmow 4ZRJns48N6VounkBpIyTU9wrBtD7PyrXitwxfAtG4D8RoLZBf8KkoukqclH5 gi1089MfYF/S1XYZ4MUbuLwR6wtKYilaqCE5vNVqFZuytD8JRPB8XHJgVd46 QYbWK6ppvTXbUD/BOAS56twAuzs9+3i4R4lfF/vHeAX7T4fnhxbmgx1e7p98 wK8rnZ0e/4p2wuEPh+eYUvfr2adz6+Ts9Ojj2flXUzpABAUn+6ef9o8pww2h vT87p88snn46eXd4PlWb3cXgMIt8Z9xR1l/+vgVvR0Xy/CbvTEsoqVXstofb Vn/Y7hkV0ayZ+/cwZmyCeam0NeJTNLfUvDvc6WH7zs6wU2peEKkGAmBciCQF gwmXpprRRyfUbPIfOKXm8IadnW6v83Jm84+Js7z2XVmxmV9Qziyae3xA3mgd 2drc3DSO2Sh1qAxm5JK9nY2czU1pfRrvu64I7ObS6S9ulkgtz2rFn6T4cHRm r4M8PT4CzEoCEO/KA3XVKpnPqTfH7LWStOsfzO/BPQXP3XHxphMof4dBUy62 7Is49uK4j68zeXSgtdaH90d73b3OHvRRYgsKkKvQvnXx4776BOYevK/RktKx zHCN2VClaxW4tuxP0U0U30U2Z1/lWBoFOl/AvfaXUqTkWZc8LvRb0QdH7xsd qKPUCNnTxmMM5Ep8T6goAUeWvpI5SA+Wsco8R/dNee24IaEzhCgZqhAVLKLe c/OWTUn8vpunNqgJIkzDTKYG+wF+RrAjyaIddL+LXEl9b57OJ9vWeS446Eim Seam7LarTW+VVKn2/RWGVTDQK1oUGJmhjHHVfaXXhj4pd8/zMUNJ6hRPrquI RPEhGFuqNjc505UOH6h03jxHom5s3i5oxwNJxoyo57aSXqp6hkW+jKX0cW8h VwLFFqDZG0t85WEDTprsBjElZjepWdm2nGJLVoNAJiLvPcTLKq1sWWyiLxM/ dJKVhVkQsWqptkpgEVFSM38k1uHOOB5fyftXkSEcq3b7qXLBfpSXVjBgntqv tFiq89jCmKLuDmd+mUjR/KX4Cdqca40lTyu+s9elJc+lF9j43AlbfMsosTmd SIQXoL97k3a/lquoQsX6I7XVsyxPkRMotECQ3WrBRHKiJOeIV1q4LajOO0M3 mI2gjD2FtjpIOOC3IANhlaRqBComx0SbW85ymcQwkcDa5QE9a7ZQyTyVL6j+ ZLmnitZDAeDg4qXA0EytF1H+sDBnCqBkwKQfggft9vM3LF3cSlcoZJyygMyz 8q1LLaZ0DiJxeL6O7B2GRVthSyUmigwoVVbzBBRV9R42sx+zidKRnCXGjgfv Kf0rt/UPOKx5IJaABZ+v3IR/QLQiPQLc/QbgnhHXRkli4U2fnNjd0hp7PwhS +Zf1Z+QlDgfPuyNr/j8JVvsH+xU6WDkLnOiGQq0W+n59ykqml5RUeY2RY4p+ 0tCkc4uJ5TMwIS15i7mS8ubPJPz+Hzk8PMfjwTJDiLaGl/g3qY8pmncooAFG UT2DycHTQ1x9YFub6tX3eZ2z+VyVE8UmUCeGVzL9E8+D3TIKAjPxAjBogZmu /wK5kn7PA90oZ2hjqsoycFbavmFqq2eiXqIvJotIC6zb+/EI+rUnnc49hsMt ezTo3A8mPKPl3OzP6K87/NIdjr5wh0ri/bt1WDEzNzZeIFUz38h3nzsAXpPB jR0+URLfOYZRo6QA70ElCyfy2UjYL4Sw2ZdhtPxdUQwg7J1A7Z4rUQxSN1J7 bxKzFnXWtbr02U9katpbZMjozTyw3RvJgRVzo6sAM62qFG0EOkFMG3mVtFi1 Za4NbkM7NBndDRrEp30VAwxNikKDzTBFQjTiKlEmPIDAroJ2QugMAR1LFQFf LqnzLZBolAyvJ1VlOc8xBQMBAfx5qnLl2apU+pWOOeh8Cs0RausnjZfbmLqf xuG2FYi5Or6B+UKoSuclKzVX5UfKAM6zWFRPdCsUHcNgs5v5gY+eFqZFV4UR FDEMLUxrjT2AmSOBOXPFpk0Fh1wV3gpsm9t4LUMz2i3QY2DidTt0niPlOI6G fPDhZKpBKCKqfBN04ciqmwlOiYbqKypZBPHMobxSh6aAbGTGaUevpBxUnqZC PKeOP6hcSuwcefuIdkP5pYfHcJUBQ2cQ8E8V7dxi9sDUXcRGORLofpV8UH13 D6bAVshSUvBImHKpqc9b9rBcGmtN3gKBbLNUJf42MzuqTB415X0oJqQEoYLX eY9WB0gMP00LMs4AIkC+OkuEGX3a04ll0Vo5NWC5gROjchTsbf4zz0pUGFTD 44pkJt46PaQMr16tyIOsdLXRpJTgeYn7H+D/V5hcL1/oGiDz/oeG+3/GHbzz ge//wYtC8P6H7uD1/p8v8lz+MMWgWurjRzXw2CAlsacW5lGr83DNz0fHD3Y+ ZBKPFBAEPnN4L68w1d69bxuPcRHMuDtW1WQgxPIqiBe0cVyph9fClODNGuGN epP+UFVLk1UZmlGvP+n0BxoeJsiV0DPxG/Y0fksY2xUMsrEeXl9jwpu11+DX 2x1U4F3JzMUja2V4vV4f4BlUf5fiFRnrHhMe/phl8xK83UEvH68zS4Ew8U22 rOHX6/c6uzV4fhSBhFw/HwDPxXTApEbn8WC3W6XfFUY9avCAMCY8P5KJcOt0 hnnrVeHNA+a6h/DzRLAG3qQ2H3jlB/i2sgxvgvPxjhJTVSac9cBTw+8Bfp4F N1ehs0wa+GXc7eC9V0cxdGn9kvjg76sL9iqN75qYcrLLtx9BtXuZgq1xNVuB 9VKq1x2MJiiNTXhZBBAb4I17434Z3u+Z7940LJpJwWyedyXucbPpKfiBY+en DYurIBZM5Fp4Y7oM6lw43lumVUkMIcuXmxaIjPt9zfZ4n4O4wiMystZDd3fS 72l4brhch0lvOB51S/BMwrcVrG4PFN2oxFaPrHKEl8Dwyui1DakGIPOZDKvr vExRE14Jvba+KGvQnfRHkxK80jqvwtvXh67A4hMcu5Ol1qVV3YgNntu6Woh0 jZA1Fk1YXdXr4cmH4R3os7wG2uuoT/ASEca34mH8PD9ZK2Q7vd7IhGfy0EPw wKQHV6heb9Dtwbr87yxOnQbKY8t1GPd3h5pSv4dX3u9AiMDxQ/kYJjBDHp3+ q9QDm23cAO8KbwUSsgbvY+JE0nHXU9ygPMGDIV552fJB/FIEeoVb703qvDMy 4dHNf4zcI/AcA2Ax3NFuZ1yDd61F2EPwRLhMV3UJNuqV5gOPqsj1nHGEJy0e 41oTnrx2bsSVnuVm/PwFciXiJ2vybzgY90x4fgSz9zi8Od5m38ThowneX8jD eA9qEpwiPJFqtATYKzcQD61xnxQsiKYsatAdk0IXATyaa69JV4462hDwXcaE FbeLQEu3WO4a8Lxifa/HrwTPp8GaBk3fgFdegO3SHZJg2F5Q45J9bsxZ4l4v GkaGHzCF5za64m33NabugE2w43jxFI5ieGiettfAm4wLSoEdzopQNsmgscav LPirvMK6MofHN5LWTezOLrsAAA+T39bB64It3jXhRTFMFPgLDaZ9V8HDT4qu g9fvgkY34c3jxBVNdJ7k41WzvWY+BpNODR57SVWZNsnhmWK+RufueMN6+gPw 0JNZOx+0xv/r9fnPu//5/HD/4OQQfi0T0Rs8fxDIvP+5fv8nlA5GOv4zHIzg d3fQh1ev939+ofgPTDtYmoFQe7+BH2X3Vq89aG9s0CaKT+f3Z3EU+eLrr990 253OYgtPjhU3//IxKD459eby5ASABg5eNsABaCeQ8QZ52XQ3HwXBwakOfA52 yK38yhCM82LMeLtIK3GsFGm/web1G9xLofA3x7IxzBtbyoff4k0MaHJ37Qfi TQgCEux8PAociPD7rfbGkaUi8ybyS/31L8n3ffl89pdex3iMlka2Ed7MpbWD t3rBPwHnHEVOsC39P8S34FV3ZtaOZ73FWPW3xWXKG7TNgrdDMQUtVox4WclK 4rjBLwxniBn4zrjVJK0wc68piUnd3Reu1DcysVDlHuHOTxBwglF+1SZtmYBl gGYpQAIDAfW/PtBMB6EpSYdg+3xOehE4Hif2YN4FwMaQv4ubXbOV2DhxFlEm X+Xk6/P6vD6vz+vz+rw+r8/r8/q8Pq/P6/P6/Ds//wsM5OizABgBAA== --0-650579519-980712685=:92933-- From owner-linux-xfs@oss.sgi.com Sun Jan 28 15:57:43 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 15:57:34 -0800 Received: from mail11.jump.net ([206.196.91.11]:26519 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 15:57:13 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0SNv5K24397; Sun, 28 Jan 2001 17:57:05 -0600 (CST) Message-ID: <3A74B1D6.250EB45F@sgi.com> Date: Sun, 28 Jan 2001 17:57:10 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: "=?iso-8859-1?Q?Fr=E9d=E9ric?= L. W. Meunier" <0@pervalidus.net> CC: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement References: <20010128175654.C6620@pervalidus> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hm - it looks like the patch that was generated includes everything from our CVS tree root, including the RPM build data and the modified installer data, which patch users really don't need... We'll get that fixed Real Soon Now. -Eric Frédéric L. W. Meunier wrote: > > Seth Mos wrote: > > > Expect heavy traffic ;-) > > OK, so before any /. DoS, could I ask why the XFS patch is so > big? Loading it on my machine was funny (24169590 bytes). > There are RedHat patches (anaconda?) and others included. > > So, what's really added/modified and gets used by > /usr/src/linux/linux-2.4.0 or whatever. And can we expect a > small patch for a future release? > > TIA. > > -- > 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR) From owner-linux-xfs@oss.sgi.com Sun Jan 28 16:00:44 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 16:00:34 -0800 Received: from [62.2.247.131] ([62.2.247.131]:11018 "EHLO delouw.ch") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 16:00:17 -0800 Received: from localhost (luc-xfs-ml@localhost) by delouw.ch (8.9.3/8.9.3) with ESMTP id BAA30182 for ; Mon, 29 Jan 2001 01:00:15 +0100 Date: Mon, 29 Jan 2001 01:00:14 +0100 (CET) From: Luc de Louw - Mailonlyuser for the SGI xfs mailinglinst To: linux-xfs@oss.sgi.com Subject: pre-release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi! I just read the announcement of Pre-Release 0.9 what means that? does it mean, the beta-state will be ended soon and xfs for linux will be stable for production? 2nd question: would xfs be included in linux 2.5? or even in a later 2.4-release? whats about the other journaling fs'es? is it possible to patch a kernel allready patched with IBM's jfs? I hear about the a lvm comming with xfs that would have about the same funcionality like the lvm of SGI's lvm and IBM's AIX-lvm does that lvm work with other fs'es? (ext2,3 jfs, reiserfs, whatever-fs) I'm sorry to bug you with that questions, maybee hundreds of other ppl made these question, but I think this is very important, that all the new journaling fs'es work togther very well.... rgds Luc de Louw From owner-linux-xfs@oss.sgi.com Sun Jan 28 16:27:24 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 16:27:04 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:14094 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 16:26:51 -0800 Received: from sydney.sydney.sgi.com ([134.14.48.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA04547 for ; Sun, 28 Jan 2001 16:26:49 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id LAA02298; Mon, 29 Jan 2001 11:25:52 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Magnus Roth cc: linux-xfs@oss.sgi.com Subject: Re: Bug: XFS prerealese for linux 2.4. In-reply-to: Your message of "Sun, 28 Jan 2001 12:11:25 -0800." <20010128201125.93490.qmail@web10011.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jan 2001 10:58:47 +1100 Message-ID: <11422.980726327@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Sun, 28 Jan 2001 12:11:25 -0800 (PST), Magnus Roth wrote: >When i use bonnie++(1.00g) on /mnt/space and using >X(XMMS playing, and also >starting other applications) at the same time, there >is a total >lookup(reset is only way to restart) after a >while(memory problem?). Linus recently found a bug in shared memory handling that has these symptoms. The fix below is extracted from 2.4.1-pre11 and ported to 2.4.0-xfs. Does it fix your problem? =========================================================================== Index: linux/mm/memory.c =========================================================================== --- /usr/tmp/TmpDir.7386-0/linux/mm/memory.c_1.42 Mon Jan 29 11:24:10 2001 +++ linux/mm/memory.c Mon Jan 29 11:22:43 2001 @@ -943,7 +943,6 @@ if (inode->i_size < offset) goto do_expand; inode->i_size = offset; - truncate_inode_pages(mapping, offset,TRUNC_TOSS); spin_lock(&mapping->i_shared_lock); if (!mapping->i_mmap && !mapping->i_mmap_shared) goto out_unlock; @@ -958,8 +957,7 @@ out_unlock: spin_unlock(&mapping->i_shared_lock); - /* this should go into ->truncate */ - inode->i_size = offset; + truncate_inode_pages(mapping, offset,TRUNC_TOSS); if (inode->i_op && inode->i_op->truncate) inode->i_op->truncate(inode); return; =========================================================================== Index: linux/mm/shmem.c =========================================================================== --- /usr/tmp/TmpDir.7386-0/linux/mm/shmem.c_1.2 Mon Jan 29 11:24:10 2001 +++ linux/mm/shmem.c Mon Jan 29 11:20:14 2001 @@ -204,8 +204,11 @@ if (info->locked) return 1; swap = __get_swap_page(2); - if (!swap.val) - return 1; + if (!swap.val) { + set_page_dirty(page); + UnlockPage(page); + return -ENOMEM; + } spin_lock(&info->lock); entry = shmem_swp_entry (info, page->index); From owner-linux-xfs@oss.sgi.com Sun Jan 28 16:50:54 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 16:50:34 -0800 Received: from mail15.jump.net ([206.196.91.15]:18366 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 16:50:14 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f0T0oD325397 for ; Sun, 28 Jan 2001 18:50:13 -0600 (CST) Message-ID: <3A74BE4A.862DBFE@sgi.com> Date: Sun, 28 Jan 2001 18:50:18 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-SGI_XFS_PRsmp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement References: <20010128175654.C6620@pervalidus> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Frédéric L. W. Meunier wrote: > So, what's really added/modified and gets used by > /usr/src/linux/linux-2.4.0 or whatever. And can we expect a > small patch for a future release? Oh, but to answer your second question, the only directories you really need are the patched linux source tree (linux/), and the cmds/ directory. SOURCES and SPECS are all RPM-build specific files (which account for about 8 megs of the expanded patch size), and SCRIPTS is for maintenance. There's also a top level Makefile (above linux/ and cmds/) that you can ignore. You can delete them all, and just build your kernel from the linux/ directory, and build the xfs tools from cmds/ See http://oss.sgi.com/projects/xfs/pr_source.html for details. -Eric From owner-linux-xfs@oss.sgi.com Sun Jan 28 17:42:24 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 17:42:04 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13389 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 17:41:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01993 for ; Sun, 28 Jan 2001 17:50:36 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA62119 for linux-xfs@oss.sgi.com; Mon, 29 Jan 2001 12:40:10 +1100 (EST) Date: Mon, 29 Jan 2001 12:40:10 +1100 (EST) From: Nathan Scott Message-Id: <200101290140.MAA62119@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cmds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:83374a Date: Sun Jan 28 17:40:10 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/quota/configure.in - 1.5 - add some checks to make sure we have headers we need for a build. cmd/quota/repquota.c - 1.10 - -v flag now prints out users who haven't used any inodes/blks yet - confused Ivan & myself till poking thru the code revealed a filter on this condition. cmd/xfsprogs/configure.in - 1.2 cmd/xfsprogs/include/builddefs.in - 1.3 - we lost the check for uuid.h at some point, add back in cos its important. From owner-linux-xfs@oss.sgi.com Sun Jan 28 20:47:36 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 20:47:15 -0800 Received: from [210.212.54.4] ([210.212.54.4]:7186 "EHLO mail.cse.iitk.ac.in") by oss.sgi.com with ESMTP id ; Sun, 28 Jan 2001 20:47:11 -0800 Received: from cseultra2.cse.iitk.ac.in (cseultra2 [172.31.16.2]) by mail.cse.iitk.ac.in (8.9.3/8.9.3) with ESMTP id KAA10903 for ; Mon, 29 Jan 2001 10:14:37 +0530 Received: from rm2 (cseproj26.cse.iitk.ac.in [172.31.17.26]) by cseultra2.cse.iitk.ac.in (8.10.1/8.10.1) with SMTP id f0T4fDJ28207 for ; Mon, 29 Jan 2001 10:11:13 +0530 (IST) Message-ID: <000801c08a77$606ef680$1a111fac@rm> From: "vivek shukla" To: Subject: query:what is the command to open x font server Date: Tue, 30 Jan 2001 10:14:48 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C08AA5.7A05A0C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C08AA5.7A05A0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dear sir/madam please tell me command to open x font server in "Red hat 7.0" and see detail of X font server. thanks, vivek ------=_NextPart_000_0005_01C08AA5.7A05A0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
dear sir/madam
 
please tell me command to open x font = server=20 in
"Red = hat 7.0" and=20 see detail of X font server.
 
thanks,
 
vivek
------=_NextPart_000_0005_01C08AA5.7A05A0C0-- From owner-linux-xfs@oss.sgi.com Sun Jan 28 21:53:35 2001 Received: by oss.sgi.com id ; Sun, 28 Jan 2001 21:53:16 -0800 Received: from perilith.com ([207.198.250.232]:1294 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Sun, 28 Jan 2001 21:52:58 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id 3306E3E018; Mon, 29 Jan 2001 00:52:53 -0500 (EST) Date: Sun, 28 Jan 2001 21:52:53 -0800 From: Drew Bloechl To: vivek shukla Cc: linux-xfs@oss.sgi.com Subject: Re: query:what is the command to open x font server Message-ID: <20010128215251.A21388@perilith.com> References: <000801c08a77$606ef680$1a111fac@rm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <000801c08a77$606ef680$1a111fac@rm>; from shukla_vivek@yahoo.com on Tue, Jan 30, 2001 at 10:14:48AM +0530 X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, Jan 30, 2001 at 10:14:48AM +0530, vivek shukla wrote: > dear sir/madam > > please tell me command to open x font server in > "Red hat 7.0" and see detail of X font server. Sorry... the "fs" in this list stands for "file system", not "font server". You might be looking for one of these: http://www.xfree86.org/mailman/listinfo -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Mon Jan 29 07:25:19 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 07:25:00 -0800 Received: from [213.11.150.158] ([213.11.150.158]:62470 "EHLO teletota.fr") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 07:24:36 -0800 Received: from XFS - 172.16.35.121 by teletota.fr with Microsoft SMTPSVC(5.5.1775.675.6); Mon, 29 Jan 2001 16:26:53 +0100 From: jms Reply-To: jimx@free.fr To: linux-xfs@oss.sgi.com Subject: cdrom Date: Mon, 29 Jan 2001 16:27:07 +0100 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01012916281800.05077@XFS> Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, I've installed a root XFS pre-release 0.9 kernel, and I don't see my ide cdrom device, normaly create on /dev/hdc on redhat7 and I think under /dev/ide/host0/bus1/target0/lun0/ for the sgi modified redhat7. Also is there a support for the Intel/PRO1000 gigabit card in your future 2.4 XFS kernel?? Thanks and regards JM STEFANI jimx@free.fr From owner-linux-xfs@oss.sgi.com Mon Jan 29 08:42:49 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 08:42:40 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:15906 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 08:42:21 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00645 for ; Mon, 29 Jan 2001 08:42:16 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA627319; Mon, 29 Jan 2001 10:40:59 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA10875; Mon, 29 Jan 2001 10:40:59 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0TGgLa09897; Mon, 29 Jan 2001 10:42:21 -0600 Message-Id: <200101291642.f0TGgLa09897@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: jimx@free.fr cc: linux-xfs@oss.sgi.com Subject: Re: cdrom In-Reply-To: Message from jms of "Mon, 29 Jan 2001 16:27:07 +0100." <01012916281800.05077@XFS> Date: Mon, 29 Jan 2001 10:42:21 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Hello, > > I've installed a root XFS pre-release 0.9 kernel, and I don't see my ide cdr > om device, normaly create on /dev/hdc on > redhat7 and I think under /dev/ide/host0/bus1/target0/lun0/ for the sgi modif > ied redhat7. Try modprobe ide-cd and then look in /dev/cdroms/ devfs is included by default and does not appear to be autoloading the ide cdrom code, you can turn this off by building your own kernel - which I would recommend to include the drivers and disk subsystems you use directly into the kernel (and xfs too!) This will speed up system boot considerably, and get rid of the need for an initial ram disk. Steve > > Also is there a support for the Intel/PRO1000 gigabit card in your future > 2.4 XFS kernel?? > > Thanks and regards > > JM STEFANI > > jimx@free.fr From owner-linux-xfs@oss.sgi.com Mon Jan 29 08:57:29 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 08:57:09 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:15226 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 08:57:03 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA05896 for ; Mon, 29 Jan 2001 08:56:04 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA628552 for ; Mon, 29 Jan 2001 10:55:47 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA87491 for ; Mon, 29 Jan 2001 10:55:47 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0TGv9j13852; Mon, 29 Jan 2001 10:57:09 -0600 Message-Id: <200101291657.f0TGv9j13852@jen.americas.sgi.com> Date: Mon, 29 Jan 2001 10:57:09 -0600 Subject: TAKE - cleanup merge slop To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing remove some hanging chads from previous merges Date: Mon Jan 29 08:55:41 PST 2001 Workarea: 128.162.184.86:/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:83386a linux/mm/page_alloc.c - 1.35 linux/include/linux/fs.h - 1.76 linux/fs/stat.c - 1.19 linux/fs/buffer.c - 1.53 From owner-linux-xfs@oss.sgi.com Mon Jan 29 10:15:59 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 10:15:39 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:13640 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 10:15:13 -0800 Received: from madurai.engr.sgi.com ([163.154.5.75]) 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 KAA05556 for ; Mon, 29 Jan 2001 10:15:04 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA69893; Mon, 29 Jan 2001 10:09:02 -0800 (PST) Message-ID: <3A75B2A6.9DACF3A1@sgi.com> Date: Mon, 29 Jan 2001 10:12:54 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: phbaer@openums.org Subject: Re: Another problem from the survey. References: <3A731BD6.384506BB@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Date: Mon Jan 22 03:51:34 2001 > Name: Baer > Email: phbaer@openums.org > Company: > XFS version: CURRENT_development_tree > NUMBER: 0 > Linux distribution: Suse > Hardware: ia32 > Manufacturer(s): IBM > Storage amount: 11 - 25 GB 24 > LVM: MD: OTHER: NONE: true > TAPEDRV > Comments: the newly formatted disc. RPM installed the first base > packages and then bacame out of memory. It seems that I/O operations on > the xfs filesystem are very expesive, because 256mb of ram and 256 mb > swap were used after a few seconds. There possibly is a memory leak in > the pagebuf or somewhere else. Can you please provide some more details? Is this during the installation that you ran into OOM? If so, are you using the X installation method? If the problem is on the installed kernel, can you indicate what you were running to induce the problem? Thanks. FWIW, I've been running fairly stressful tests on a 64MB system for > 24 hrs without problems ... cheers, -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jan 29 10:18:59 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 10:18:40 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:45897 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 10:18:37 -0800 Received: from madurai.engr.sgi.com ([163.154.5.75]) 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 KAA05517 for ; Mon, 29 Jan 2001 10:18:37 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA70723; Mon, 29 Jan 2001 10:13:11 -0800 (PST) Message-ID: <3A75B39F.1DF68B03@sgi.com> Date: Mon, 29 Jan 2001 10:17:03 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: cet@carlthompson.net Subject: Re: Problem report from survey References: <3A7317CA.18FE658F@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > Date: Fri Jan 26 14:29:33 2001 > Name: Thompson > Email: cet@carlthompson.net > Company: Home > XFS version: XFS_PRERELEASE > NUMBER: 0 > Linux distribution: Redhat > Hardware: ia32 > Manufacturer(s): Maxtor > Storage amount: 11 - 25 GB > LVM: MD: OTHER: NONE: true > TAPEDRV > > Comments: After rebooting, the system was able to create and mount XFS > partitions, but COULD NOT LOAD ANY KERNEL MODULES!!! Any attempts to > load modules resulted in unresolved symbol errors. This problem > occurred for each and every kernel module. A kernel built without the > XFS kernel patches and configured with the exact same options (except > those relating to XFS) was able to load modules properly. The only > filesystems compiled directly into the kernel (not in a module) were > Ext2, XFS, and Reiserfs. (And of course /proc and /dev/pts.) I am using > modutils 2.4.2 (the latest release) and 2.4.0. I am interested in > converting my filesystems from Reiserfs to XFS. Any ideas? > Thanks, Carl Thompson There are Makefile issues with changes that went into test12, which has problems with defining EXTRAVERSION (xfs adds -XFS to EXTRAVERSION in the top level Makefile). Here's a comment from Keith Owens, a build maintainer: Broken makefile system. FAQ http://www.tux.org/lkml/#s8-8 More practically, I found that after a make mrproper, etc. if you "touch Makefile" before proceeding with the compilation, the versioning comes out right. If you continue to see problems, please let us know. cheers, -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jan 29 10:36:19 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 10:35:59 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57365 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 10:35:52 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA03860 for ; Mon, 29 Jan 2001 10:44:56 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA92874; Mon, 29 Jan 2001 10:34:33 -0800 (PST) Date: Mon, 29 Jan 2001 10:32:29 -0800 (PST) From: Tom Duffy To: jms cc: Subject: Re: cdrom In-Reply-To: <01012916281800.05077@XFS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing the way to fix this is add in your /etc/modules.conf, then line include /etc/modules.alsa then, create this file (if it is not already there) modules.devfs: # /etc/modules.devfs # Richard Gooch 3-JUL-2000 # # THIS IS AN AUTOMATICALLY GENERATED FILE. DO NOT EDIT!!! # THIS FILE WILL BE OVERWRITTEN EACH TIME YOU INSTALL DEVFSD!!! # Modify /etc/modules.conf instead. # This file comes with devfsd-vDEVFSD-VERSION which is available from: # http://www.atnf.csiro.au/~rgooch/linux/ # or directly from: # ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/devfsd-vDEVFSD-VERSION.tar.gz ############################################################################### # Sample configurations that you may want to place in /etc/modules.conf # #alias /dev/sound sb #alias /dev/v4l bttv #alias /dev/misc/watchdog pcwd #alias gen-md raid0 #alias /dev/joysticks joystick #probeall scsi-hosts sym53c8xx ############################################################################### # Generic section: do not change or copy # # All HDDs probeall /dev/discs scsi-hosts sd_mod ide-probe-mod ide-disk DAC960 # All CD-ROMs probeall /dev/cdroms scsi-hosts sr_mod ide-probe-mod ide-cd # All tapes probeall /dev/tapes scsi-hosts st ide-probe-mod ide-tape # All SCSI devices probeall /dev/scsi scsi-hosts sd_mod sr_mod st sg # All IDE devices probeall /dev/ide ide-probe-mod ide-disk ide-cd ide-tape ide-floppy # SCSI HDDs probeall /dev/sd scsi-hosts sd_mod alias /dev/sd* /dev/sd # SCSI CD-ROMs probeall /dev/sr scsi-hosts sr_mod alias /dev/sr* /dev/sr # SCSI tapes probeall /dev/st scsi-hosts st alias /dev/st* /dev/st alias /dev/nst* /dev/st # SCSI generic probeall /dev/sg scsi-hosts sg alias /dev/sg* /dev/sg # Floppies alias /dev/floppy floppy alias /dev/fd* floppy # RAMDISCs alias /dev/rd rd alias /dev/ram* rd # Loop devices alias /dev/loop* loop # Meta devices alias /dev/md* gen-md # Parallel port printers alias /dev/printers* lp alias /dev/lp* /dev/printers # Soundcard alias /dev/audio /dev/sound alias /dev/mixer /dev/sound alias /dev/dsp /dev/sound alias /dev/dspW /dev/sound alias /dev/midi /dev/sound # Joysticks alias /dev/js* /dev/joysticks # Serial ports alias /dev/tts* serial alias /dev/ttyS* /dev/tts alias /dev/cua* /dev/tts # Miscellaneous devices alias /dev/misc/atibm atixlmouse alias /dev/misc/inportbm msbusmouse alias /dev/misc/logibm busmouse # PPP devices alias /dev/ppp* ppp_generic # Video capture devices alias /dev/video* /dev/v4l alias /dev/vbi* /dev/v4l # Tell devfs that /dev/hd* devices are ide. alias /dev/hd* /dev/ide # Mylex DAC960 RAID devices probeall /dev/dac960 DAC960 alias /dev/rd/c* /dev/dac960 # Pull in the configuration file. Do this last because modprobe(8) processes in # per^H^H^Hreverse order and the sysadmin may want to over-ride what is in the # generic file include /etc/modules.conf On Mon, 29 Jan 2001, jms wrote: > Hello, > > I've installed a root XFS pre-release 0.9 kernel, and I don't see my ide cdrom device, normaly create on /dev/hdc on > redhat7 and I think under /dev/ide/host0/bus1/target0/lun0/ for the sgi modified redhat7. > > Also is there a support for the Intel/PRO1000 gigabit card in your future > 2.4 XFS kernel?? > > Thanks and regards > > JM STEFANI > > jimx@free.fr > From owner-linux-xfs@oss.sgi.com Mon Jan 29 10:36:19 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 10:36:10 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:36432 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 10:36:01 -0800 Received: from eric2.austin.sgi.com ([169.238.86.147]) 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 KAA03550 for ; Mon, 29 Jan 2001 10:36:00 -0800 (PST) mail_from (eric@eric2.austin.sgi.com) Received: (from eric@localhost) by eric2.austin.sgi.com (8.11.0/8.11.0) id f0TIdRE10599 for linux-xfs@oss.sgi.com; Mon, 29 Jan 2001 12:39:27 -0600 Date: Mon, 29 Jan 2001 12:39:27 -0600 From: Eric Sandeen Message-Id: <200101291839.f0TIdRE10599@eric2.austin.sgi.com> Subject: TAKE - kernel-2.4.spec To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Date: Mon Jan 29 10:34:56 PST 2001 Workarea: eric2.austin.sgi.com:/home/eric/xfs/workarea-clean automatic module loading was not functioning due to missing /etc/modules.devfs file in devfsd RPM The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:83395a SPECS/kernel-2.4.spec - 1.57 - Include /etc/modules.devfs in devfsd RPM From owner-linux-xfs@oss.sgi.com Mon Jan 29 11:18:19 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 11:18:00 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:39684 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Mon, 29 Jan 2001 11:17:57 -0800 Received: (qmail 27557 invoked from network); 29 Jan 2001 19:17:47 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 29 Jan 2001 19:17:47 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Tom Duffy cc: jms , linux-xfs@oss.sgi.com Subject: Re: cdrom In-reply-to: Your message of "Mon, 29 Jan 2001 10:32:29 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jan 2001 06:17:47 +1100 Message-ID: <21634.980795867@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, 29 Jan 2001 10:32:29 -0800 (PST), Tom Duffy wrote: >the way to fix this is add in your /etc/modules.conf, then line > >include /etc/modules.alsa alsa? I assume you meant devfs. >then, create this file (if it is not already there) modules.devfs: devfsd is supposed to look in /etc/modules.devfs automatically, which then includes /etc/modules.conf. Adding /etc/modules.devfs to modules.conf will probably result in an include loop. From owner-linux-xfs@oss.sgi.com Mon Jan 29 11:22:20 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 11:22:00 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:41772 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 11:21:55 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA29814 for ; Mon, 29 Jan 2001 11:20:56 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA60472; Mon, 29 Jan 2001 11:20:34 -0800 (PST) Date: Mon, 29 Jan 2001 11:18:30 -0800 (PST) From: Tom Duffy To: Keith Owens cc: jms , Subject: Re: cdrom In-Reply-To: <21634.980795867@ocs3.ocs-net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Tue, 30 Jan 2001, Keith Owens wrote: > On Mon, 29 Jan 2001 10:32:29 -0800 (PST), > Tom Duffy wrote: > >the way to fix this is add in your /etc/modules.conf, then line > > > >include /etc/modules.alsa > > alsa? I assume you meant devfs. oh, my mistake. we have a modules.alsa which makes alsa happy with devfs and such. i think nathans fixed the problem earlier which was that modules.devfs was not included in the devfsd rpm. so, just adding that file into /etc should do the trick. -tduffy From owner-linux-xfs@oss.sgi.com Mon Jan 29 12:56:10 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 12:56:02 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:17939 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 12:55:46 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07058 for ; Mon, 29 Jan 2001 12:55:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA632453 for ; Mon, 29 Jan 2001 14:53:54 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23376 for ; Mon, 29 Jan 2001 14:53:53 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0TKtGB02483; Mon, 29 Jan 2001 14:55:16 -0600 Message-Id: <200101292055.f0TKtGB02483@jen.americas.sgi.com> Date: Mon, 29 Jan 2001 14:55:16 -0600 Subject: TAKE - more minor cleanup To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Put back some debug checks removed in the last mod, they are useful for catching vm changes, remove some definitions we do not need from elsewhere. Date: Mon Jan 29 12:53:50 PST 2001 Workarea: 128.162.184.86:/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:83425a linux/mm/page_alloc.c - 1.36 - Put back debug check - ananth complained.... linux/kernel/ksyms.c - 1.71 - Remove unused export and unneeded extern linux/fs/buffer.c - 1.54 - Put back debug check - ananth complained.... linux/fs/pagebuf/page_buf.c - 1.50 - remove unneeded extern From owner-linux-xfs@oss.sgi.com Mon Jan 29 15:30:50 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 15:30:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:31608 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 15:30:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08114 for ; Mon, 29 Jan 2001 15:29:15 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA47969; Tue, 30 Jan 2001 10:28:48 +1100 (EST) Date: Tue, 30 Jan 2001 10:28:48 +1100 (EST) From: Nathan Scott Message-Id: <200101292328.KAA47969@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 813772 - attr, acl, xfsdump, xfsprogs rpms put man pages in /man? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This'll fix that problem you just saw, Tom. Modid: 2.4.x-xfs:slinx:83453a Date: Mon Jan 29 15:27:23 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/configure.in - 1.2 cmd/attr/configure.in - 1.2 cmd/dmapi/configure.in - 1.3 cmd/xfsdump/configure.in - 1.3 cmd/xfsprogs/configure.in - 1.3 cmd/xfstests/configure.in - 1.3 - fix use of potentially uninitialised variable in deciding where to install man pages and how to build them. From owner-linux-xfs@oss.sgi.com Mon Jan 29 15:50:30 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 15:50:21 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:11879 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 15:50:02 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09214 for ; Mon, 29 Jan 2001 15:49:53 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA10841 for linux-xfs@oss.sgi.com; Tue, 30 Jan 2001 10:48:31 +1100 (EST) Date: Tue, 30 Jan 2001 10:48:31 +1100 (EST) From: Nathan Scott Message-Id: <200101292348.KAA10841@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:83456a Date: Mon Jan 29 15:49:06 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs linux/fs/dquot.c - 1.21 - remove unnecessary include. From owner-linux-xfs@oss.sgi.com Mon Jan 29 16:42:30 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 16:42:21 -0800 Received: from mail11.jump.net ([206.196.91.11]:43495 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 16:42:05 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0U0g2W00994; Mon, 29 Jan 2001 18:42:02 -0600 (CST) Message-ID: <3A760DDE.FA5114EA@sgi.com> Date: Mon, 29 Jan 2001 18:42:06 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: jimx@free.fr CC: linux-xfs@oss.sgi.com Subject: Re: cdrom References: <01012916281800.05077@XFS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing jms wrote: > Also is there a support for the Intel/PRO1000 gigabit card in your future > 2.4 XFS kernel?? I think that there is a patch for this card included in the kernel SRPM, but the module wasn't built. Intel's support page for this card is here: http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415 and it looks like it's pretty simple to compile & install their driver. Apparently license problems are keeping it out of the kernel proper... -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 29 17:32:51 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 17:32:42 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22610 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 17:32:31 -0800 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA07843 for ; Mon, 29 Jan 2001 17:41:35 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.66.65]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA50104 for ; Mon, 29 Jan 2001 17:34:52 -0800 (PST) Received: from sgi.com (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 99E2A83C22 for ; Mon, 29 Jan 2001 17:30:54 -0800 (PST) Message-ID: <3A76194E.8366CD4A@sgi.com> Date: Mon, 29 Jan 2001 17:30:54 -0800 From: Florin Andrei Organization: SGI X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-lvs-1.0.3-reiserfs-3.5.29 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement References: <4.3.2.7.2.20010128141834.037976b0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Seth Mos wrote: > > The announcement made it on http://linuxtoday.com/ I think XFS must be announced also on Freshmeat. This is a site of a huge importance in the Open Source world, and especially for Linux-oriented software. If you will announce every minor release on Freshmeat (like many other people do with their software), you will atract more users, so you will get a lot more feedback, resulting in a faster improvement of the code... ;-) http://freshmeat.net/ -- Florin Andrei From owner-linux-xfs@oss.sgi.com Mon Jan 29 18:24:01 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 18:23:41 -0800 Received: from perilith.com ([207.198.250.232]:44808 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Mon, 29 Jan 2001 18:23:40 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id 3BCD03E017; Mon, 29 Jan 2001 21:23:39 -0500 (EST) Date: Mon, 29 Jan 2001 18:23:39 -0800 From: Drew Bloechl To: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement Message-ID: <20010129182338.A12274@perilith.com> References: <4.3.2.7.2.20010128141834.037976b0@pop.xs4all.nl> <3A76194E.8366CD4A@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <3A76194E.8366CD4A@sgi.com>; from florin@sgi.com on Mon, Jan 29, 2001 at 05:30:54PM -0800 X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Mon, Jan 29, 2001 at 05:30:54PM -0800, Florin Andrei wrote: > I think XFS must be announced also on Freshmeat. This is a site of a > huge importance in the Open Source world, and especially for > Linux-oriented software. If you will announce every minor release on > Freshmeat (like many other people do with their software), you will > atract more users, so you will get a lot more feedback, resulting in a > faster improvement of the code... ;-) http://freshmeat.net/projects/xfs/ -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Mon Jan 29 21:49:42 2001 Received: by oss.sgi.com id ; Mon, 29 Jan 2001 21:49:33 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:49160 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 29 Jan 2001 21:49:10 -0800 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA05415 for ; Mon, 29 Jan 2001 21:49:02 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA09397; Tue, 30 Jan 2001 16:47:41 +1100 (EST) Date: Tue, 30 Jan 2001 16:47:41 +1100 (EST) From: Nathan Scott Message-Id: <200101300547.QAA09397@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: tduffy@engr.sgi.com Subject: TAKE - build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fix for the gzipped man page issue which Tom came across, plus a few unrelated minor fixes found in the process. Modid: 2.4.x-xfs:slinx:83482a Date: Mon Jan 29 21:42:55 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/build/rpm/acl.spec.in - 1.2 cmd/attr/build/rpm/attr.spec.in - 1.2 cmd/dmapi/build/rpm/dmapi.spec.in - 1.2 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.3 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.5 - append a '*' to man page entries in the manifest (keiths suggestion). cmd/acl/man/man2/Makefile - 1.2 cmd/acl/man/man3/Makefile - 1.2 cmd/attr/man/man2/Makefile - 1.2 cmd/attr/man/man3/Makefile - 1.2 - development man pages, install in development package. cmd/acl/build/rpm/Makefile - 1.2 cmd/attr/build/rpm/Makefile - 1.2 cmd/dmapi/build/rpm/Makefile - 1.2 cmd/xfsdump/build/rpm/Makefile - 1.2 cmd/xfsprogs/build/rpm/Makefile - 1.3 - add missing macro translations for spec file to be generated correctly. cmd/acl/VERSION - 1.2 cmd/acl/doc/CHANGES - 1.2 cmd/attr/VERSION - 1.2 cmd/attr/doc/CHANGES - 1.2 cmd/dmapi/VERSION - 1.2 cmd/dmapi/doc/CHANGES - 1.2 cmd/xfsdump/VERSION - 1.2 cmd/xfsdump/doc/CHANGES - 1.2 cmd/xfsprogs/VERSION - 1.2 cmd/xfsprogs/doc/CHANGES - 1.2 - roll minor version for accumulated packaging changes. From owner-linux-xfs@oss.sgi.com Tue Jan 30 09:46:19 2001 Received: by oss.sgi.com id ; Tue, 30 Jan 2001 09:46:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:34657 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 30 Jan 2001 09:45:55 -0800 Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04059 for ; Tue, 30 Jan 2001 09:44:55 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.66.65]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA58674 for ; Tue, 30 Jan 2001 09:48:16 -0800 (PST) Received: from sgi.com (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 6B23783C31 for ; Tue, 30 Jan 2001 09:44:29 -0800 (PST) Message-ID: <3A76FD7D.6A49B5F0@sgi.com> Date: Tue, 30 Jan 2001 09:44:29 -0800 From: Florin Andrei Organization: SGI X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-lvs-1.0.3-reiserfs-3.5.29 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS prerelease announcement References: <4.3.2.7.2.20010128141834.037976b0@pop.xs4all.nl> <3A76194E.8366CD4A@sgi.com> <20010129182338.A12274@perilith.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Drew Bloechl wrote: > > On Mon, Jan 29, 2001 at 05:30:54PM -0800, Florin Andrei wrote: > > I think XFS must be announced also on Freshmeat. This is a site of a > > huge importance in the Open Source world, and especially for > > Linux-oriented software. If you will announce every minor release on > > Freshmeat (like many other people do with their software), you will > > atract more users, so you will get a lot more feedback, resulting in a > > faster improvement of the code... ;-) > > http://freshmeat.net/projects/xfs/ Sorry, i missed the announce on Sunday. :-/ -- Florin Andrei From owner-linux-xfs@oss.sgi.com Tue Jan 30 18:39:34 2001 Received: by oss.sgi.com id ; Tue, 30 Jan 2001 18:39:25 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2390 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 30 Jan 2001 18:39:06 -0800 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA07676; Tue, 30 Jan 2001 18:48:11 -0800 (PST) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA05447; Tue, 30 Jan 2001 18:39:04 -0800 (PST) Date: Tue, 30 Jan 2001 18:39:04 -0800 (PST) Message-Id: <200101310239.SAA05447@info.engr.sgi.com> X-Pv-Incident: 813113 webPV: info.engr webExec: bugs_update,pvincident Reply-To: sgi.bugs.xfs@fido.engr.sgi.com From: pv@relay.sgi.com (cvduser@csd.sgi.com) Subject: UPDATE 813113 - kswapd issues To: nb@sgi.com Cc: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=813113 Status : open Priority : 2 Assigned Engineer : nb Submitter : ananth Opened Date : 01/22/01 *Modified User : cvduser *Modified User Domain : csd *Customer Viewable Description : WITHHELD: linux bug *Description : Below is the state of a system that has kswapd (pid = 3) and a process performing I/O (pid = 1120) that are deadlocked waiting for each other. I'm sure that the wakeup_kswapd() changes in 2.4.1preX change this situation somewhat. However, in the long run, allocating memory under IOLOCK could still leave avenues for similar problems. Steve, we'll use this bug to record problems in this area. This instance is the fdatasync case, while running a 4-threaded doio on a 64MB machine (takes about an hour to hit it). ..... ========================== ADDITIONAL INFORMATION (UPDATE) From: cvduser@csd (BWX) Date: Jan 30 2001 06:39:03PM ========================== Linux bug. No customer viewable description at this time. kroy From owner-linux-xfs@oss.sgi.com Tue Jan 30 19:22:04 2001 Received: by oss.sgi.com id ; Tue, 30 Jan 2001 19:21:55 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:46603 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 30 Jan 2001 19:21:36 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA26065 for ; Tue, 30 Jan 2001 19:20:35 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA90302 for linux-xfs@oss.sgi.com; Wed, 31 Jan 2001 14:20:13 +1100 (EST) Date: Wed, 31 Jan 2001 14:20:13 +1100 (EST) From: Nathan Scott Message-Id: <200101310320.OAA90302@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing (this is closer to the repquota output you're after, Ivan). Modid: 2.4.x-xfs:slinx:83628a Date: Tue Jan 30 19:20:28 PST 2001 Workarea: snort:/diskb/build4/nathans/linux-xfs Author: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/quota/quotaops.c - 1.7 - fix reporting breakage in presence of nfs mounts (all cases). cmd/quota/repquota.c - 1.12 - make -v output more meaningful. From owner-linux-xfs@oss.sgi.com Tue Jan 30 23:10:46 2001 Received: by oss.sgi.com id ; Tue, 30 Jan 2001 23:10:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33632 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 30 Jan 2001 23:10:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA06315 for ; Tue, 30 Jan 2001 23:19:37 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA67738 for linux-xfs@oss.sgi.com; Wed, 31 Jan 2001 18:09:13 +1100 (EST) Date: Wed, 31 Jan 2001 18:09:13 +1100 (EST) From: Timothy Shimmin Message-Id: <200101310709.SAA67738@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libacl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Fix acl_get, acl_set error code setting in libacl. Error cases were getting quashed with errno value of 1. --Tim Modid: 2.4.x-xfs:slinx:83634a Date: Tue Jan 30 23:08:16 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs-acl Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/libacl/acl.c - 1.3 - Don't incorrectly override the errno with the wrong error number - the _syscall macro sets errno. cmd/xfstests/051 - 1.2 - If the syscall for acl_get/acl_set returns ENOSYS and hence the ACLs have been config'ed off, then don't run the test. cmd/xfstests/common.rc - 1.3 - Minor addition to output notrun msg in case one wants to run test from command line instead of check. From owner-linux-xfs@oss.sgi.com Wed Jan 31 01:07:27 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 01:07:17 -0800 Received: from drone4-svc-skyt.qsi.net.nz ([202.89.128.4]:16915 "HELO drone4.qsi.net.nz") by oss.sgi.com with SMTP id ; Wed, 31 Jan 2001 01:06:57 -0800 Received: (qmail 87533 invoked by uid 0); 31 Jan 2001 09:06:54 -0000 Received: from unknown (HELO adam) ([202.89.144.118]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 31 Jan 2001 09:06:54 -0000 From: "Adam Warner" To: Cc: "Eric Sandeen" Subject: RE: xfs installer (SGI Pre-Release ISO) Date: Wed, 31 Jan 2001 22:07:20 +1200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3A7737FA.251D0453@sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Eric and the SGI XFS Mailing List, My HPT366 controller was recognised which was great. I know Linus made mention of a 2.4.0 incompatibility with the HPT366 and IBM hard disks that is fixed in 2.4.1 (and this is my configuration): http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg26132.html My motherboard is an Abit BP6 (Intel Celeron SMP) My boot hard disk is on hde (First Primary HPT366 controller. First two IDE controllers are ATA-33). I installed / to /dev/hde1. Unfortunately after getting through the entire install I couldn't boot the OS. No message displayed whatsoever after attempting to boot the first partition. And strangely the boot disk did nothing except turn the boot process over to the HD MBR :-( The boot disk contains: initrd.img lost+found vmlinuz-2.4.0-SGI_XFS_PR So I'm stuck. I know Redhat has a tendency to attempt illegal lilo configurations (e.g. by putting an entry into lilo.conf that lilo cannot see). If this happens lilo never finishes executing and the hard disk is never ready for booting. I've had this happen to me before and solved it by booting using the boot disk created during install, editing lilo.conf and then running lilo again. Because of a compounded error with the boot disk I never got this chance. Here's the rest of my installation comments: 1. Liked the SGI colour scheme and installer :-) 2. Your time zone selection missed out "Pacific Rim". It was still possible to select Auckland (New Zealand) from the World Map. 3. No ability to select 32 bit display modes for my 3dfx Voodoo3 3000. 4. On the first install I tested the screen resolution. Even though I was able to see the message that the display mode was OK and click on it, the installer display was then corrupted and I had to hard reset and start again (BTW I chose 1152x854, 24 bit). Regards, Adam From owner-linux-xfs@oss.sgi.com Wed Jan 31 01:29:57 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 01:29:48 -0800 Received: from moe.rice.edu ([128.42.5.4]:19926 "EHLO moe.rice.edu") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 01:29:43 -0800 Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116]) by moe.rice.edu (8.9.0/8.9.0) with ESMTP id DAA16867 for ; Wed, 31 Jan 2001 03:29:42 -0600 (CST) Received: (from rjain@localhost) by photino.sid.rice.edu (8.11.2/8.11.2/Debian 8.11.2-1) id f0V9Tg106878 for linux-xfs@oss.sgi.com; Wed, 31 Jan 2001 03:29:42 -0600 From: Rahul Jain Date: Wed, 31 Jan 2001 03:29:41 -0600 To: linux-xfs@oss.sgi.com Subject: XFS bug Message-ID: <20010131032941.A6858@photino.sid.rice.edu> Reply-To: rahul@rice.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On a CVS checkout of xfs-2.4-linux compiled with gcc 2.95.3 (in debian sid), with -march=k6 added to the compilation flags, I ran the fsstress test program, and after some time, recieved the following error: ===== Jan 31 02:26:40 photino kernel: XFS assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: xfs_trans.c, line: 335 Jan 31 02:26:41 photino kernel: kernel BUG at debug.c:48! Jan 31 02:26:41 photino kernel: invalid operand: 0000 Jan 31 02:26:41 photino kernel: CPU: 0 Jan 31 02:26:42 photino kernel: EIP: 0010:[assfail+42/48] Jan 31 02:26:42 photino kernel: EFLAGS: 00010282 Jan 31 02:26:42 photino kernel: eax: 0000001a ebx: c65836e0 ecx: c0310588 edx: c0310588 Jan 31 02:26:42 photino kernel: esi: fffffff1 edi: 00000000 ebp: c6611c78 esp: c6611b3c Jan 31 02:26:42 photino kernel: ds: 0018 es: 0018 ss: 0018 Jan 31 02:26:42 photino kernel: Process page_daemon (pid: 1811, stackpage=c6611000) Jan 31 02:26:42 photino kernel: Stack: c02d25d7 c02d26ae 00000030 c01c3126 c02cbf20 c02cbd76 0000014f c6611c78 Jan 31 02:26:42 photino kernel: fffffff1 c016a6da c65836e0 00000004 fffffff1 c7da6dd8 00000001 c016d018 Jan 31 02:26:42 photino kernel: c6611c78 c7da6c00 00044c91 00000000 c6611c78 c6611dc0 c6611dc0 c7da6c00 Jan 31 02:26:42 photino kernel: Call Trace: [xfs_trans_mod_sb+322/680] [xfs_alloc_ag_vextent+606/632] [xfs_alloc_vextent+552/1256] [xfs_bmap_alloc+5617/6524] [_page_buf_page_apply+263/280] [xfs_mod_incore_sb+30/40] [xfs_bmapi+1974/5984] Jan 31 02:26:43 photino kernel: [xlog_state_release_iclog+265/280] [] [xfs_strategy+1683/2600] [create_buffers+96/432] [free_shortage+25/176] [balance_dirty_state+57/92] [balance_dirty+11/28] [linvfs_pb_bmap+154/164] ===== I had to ctrl-c from the fsstress process to stop it at that point, since it seem hung, and running it again managed to lock my X session (presumably waiting to use some files on /var, my XFS partition (and I have /tmp -> /var/tmp/tmp)). Using magic sysrq, I managed to sync, umount, and reboot, and it seems that everything carried on fine, except for some string of nulls in /var/log/messages in the error message I included above. Fortunately, /var/log/syslog also had a copy of the same error message. And so, I'll end my rambling. Feel free to ask any questions, and thanks to all the XFS team members and to SGI for making it possible for me to use such an advanced and powerful filesystem on my desktop computer. Here's to a quick maturation of the Linux port! :) -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request. From owner-linux-xfs@oss.sgi.com Wed Jan 31 03:28:09 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 03:27:59 -0800 Received: from perilith.com ([207.198.250.232]:62728 "HELO easywayout.perilith.com") by oss.sgi.com with SMTP id ; Wed, 31 Jan 2001 03:27:49 -0800 Received: by easywayout.perilith.com (Postfix, from userid 1034) id E5CDA3E017; Wed, 31 Jan 2001 06:27:45 -0500 (EST) Date: Wed, 31 Jan 2001 03:27:45 -0800 From: Drew Bloechl To: rahul@rice.edu Cc: linux-xfs@oss.sgi.com Subject: Re: XFS bug Message-ID: <20010131032744.A30113@perilith.com> References: <20010131032941.A6858@photino.sid.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010131032941.A6858@photino.sid.rice.edu>; from rjain@rice.edu on Wed, Jan 31, 2001 at 03:29:41AM -0600 X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5 E455 D831 31A3 3385 5516 X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31, 2001 at 03:29:41AM -0600, Rahul Jain wrote: > On a CVS checkout of xfs-2.4-linux compiled with gcc 2.95.3 (in debian sid), > with -march=k6 added to the compilation flags, I ran the fsstress test program, > and after some time, recieved the following error: I'm pretty sure XFS still wants gcc 2.91.66. You must have hacked the Makefile to get it to compile, right? I realize that that specific version of gcc isn't in Debian, however you can take Redhat's RPM of kgcc from 7.0 and use alien to convert it to deb. You can then do this in the toplevel Makefile: #comment out this line if compiling on RH 7.0 #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 # AND uncomment the following line CC = $(CROSS_COMPILE)kgcc I haven't had any problems with this setup yet (going on a few months with /home on XFS). -- Drew Bloechl drew@cesspool.net PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Wed Jan 31 04:37:38 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 04:37:29 -0800 Received: from diver.doc.ic.ac.uk ([146.169.1.47]:38152 "EHLO diver.doc.ic.ac.uk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 04:37:10 -0800 Received: from sytry.doc.ic.ac.uk ([146.169.5.24] ident=root) by diver.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 14NwVO-0005Rk-00 for linux-xfs@oss.sgi.com; Wed, 31 Jan 2001 12:36:58 +0000 Received: (from dpw@localhost) by sytry.doc.ic.ac.uk (8.9.3/8.8.8) id MAA08026; Wed, 31 Jan 2001 12:36:54 GMT X-Authentication-Warning: sytry.doc.ic.ac.uk: dpw set sender to dpw@sytry.doc.ic.ac.uk using -f To: linux-xfs@oss.sgi.com Subject: pagebuf_prepare_write doesn't kmap the page From: David Wragg Date: 31 Jan 2001 12:36:53 +0000 Message-ID: Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing I'm testing XFS (from CVS as of sometime yesterday) on a machine with 1GB memory and the kernel built with CONFIG_HIGHMEM. The kernel contains code of my own which is provoking the problem, though it isn't the root cause. What happens is that inside the kunmap in pagebuf_commit_write, the check in kunmap_high() that the page is already mapped fails. pagebuf_prepare_write isn't leaving the page mapped as it should (if successful). I realize that XFS doesn't use generic_file_write itself, so this bug doesn't affect XFS as is (pagebuf_generic_file_write correctly kmaps/kunmaps). But since the pagebuf_{prepare,commit}_write are exported to the rest of the kernel through the inode a_ops, it would be nice if they followed the Linux semantics. David Wragg (please Cc: me on follow-ups, I'm not subscribed to this list) From owner-linux-xfs@oss.sgi.com Wed Jan 31 04:57:58 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 04:57:49 -0800 Received: from dep.biol.rug.nl ([129.125.143.1]:8720 "EHLO dep.biol.rug.nl") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 04:57:30 -0800 Received: from biol.rug.nl (imenz05.biol.rug.nl [129.125.132.245]) by dep.biol.rug.nl (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA23798; Wed, 31 Jan 2001 13:57:28 +0100 X-Authentication-Warning: dep.biol.rug.nl: Host imenz05.biol.rug.nl [129.125.132.245] claimed to be biol.rug.nl Message-ID: <3A780BB6.2F6F3054@biol.rug.nl> Date: Wed, 31 Jan 2001 13:57:26 +0100 From: Aldert Zomer X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Wragg CC: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing David Wragg wrote: > > I'm testing XFS (from CVS as of sometime yesterday) on a machine with > 1GB memory and the kernel built with CONFIG_HIGHMEM. The kernel > contains code of my own which is provoking the problem, though it > isn't the root cause. Hi, I'm using XFS on a SMP machine with 2 GB, also built with CONFIG_HIGHMEM. I'm receiving these errors after the machine has been up for a while. I didn't have this problem with the standard 2.4.0 kernel or with a 2.2.18 kernel. Or my memory is suddenly faulty, or perhaps there is a problem with the 2.4.0-XFS kernel. Can anyone help me here? It's a redhat7 box, all the latest patches applied, 2.4.0-XFS kernel from cvs (from 30 januari) build with kgcc. snippet from /var/log/messages: Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, but trying to continue Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, but trying to continue Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with your RAM chips Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with your RAM chips I've placed /var/log/dmesg online for some more information about my system: http://molgen.biol.rug.nl/dmesg some information about mounted partitions: [root@molgen html]# mount /dev/hda8 on / type ext2 (rw) none on /proc type proc (rw) /dev/hda1 on /boot type ext2 (rw) /dev/hda6 on /home type ext2 (rw) /dev/hda5 on /usr type ext2 (rw) /dev/hda7 on /var type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /mnt/sda1 type ext2 (rw) /dev/sdb1 on /mnt/sdb1 type xfs (rw) -- Ing. Aldert Zomer, | Tel: +31 50 36 32 360 Research Technician, | Fax: +31 50 36 35 205 IMEnz Bioengineering, | Email: zomeral@biol.rug.nl PO BOX 14, 9750 AA Haren, Netherlands | Homepage: http://www.imenz.com ------------------------------------------------------------------------ Automated Medline search: http://molgen.biol.rug.nl/cgi-bin/biomail/users.pl From owner-linux-xfs@oss.sgi.com Wed Jan 31 05:13:09 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 05:13:00 -0800 Received: from diver.doc.ic.ac.uk ([146.169.1.47]:11530 "EHLO diver.doc.ic.ac.uk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 05:12:41 -0800 Received: from sytry.doc.ic.ac.uk ([146.169.5.24] ident=root) by diver.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 14Nx3l-0005cA-00; Wed, 31 Jan 2001 13:12:29 +0000 Received: (from dpw@localhost) by sytry.doc.ic.ac.uk (8.9.3/8.8.8) id NAA08129; Wed, 31 Jan 2001 13:12:27 GMT X-Authentication-Warning: sytry.doc.ic.ac.uk: dpw set sender to dpw@sytry.doc.ic.ac.uk using -f To: Aldert Zomer Cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page References: <3A780BB6.2F6F3054@biol.rug.nl> From: David Wragg Date: 31 Jan 2001 13:12:27 +0000 In-Reply-To: Aldert Zomer's message of "Wed, 31 Jan 2001 13:57:26 +0100" Message-ID: Lines: 22 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Aldert Zomer writes: > Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, > but trying to continue > Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, > but trying to continue > Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with > your RAM chips > Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with > your RAM chips Unlikely to be XFS related. Have you tried plain 2.4.0 on the same machine? Do the usual things to tease out a hardware problem: Run memtest, switch the memory (or remove some of the sticks), run lots of parallel kernel builds for a few days, etc. (Unless you have been hacking your kernel, you won't have the same problem I'm having. The code in question never gets run in 2.4.0-XFS, as far as I can tell.) David Wragg From owner-linux-xfs@oss.sgi.com Wed Jan 31 07:30:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 07:30:01 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:52790 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 07:29:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA02321 for ; Wed, 31 Jan 2001 07:29:52 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA654550; Wed, 31 Jan 2001 09:27:16 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA77700; Wed, 31 Jan 2001 09:27:16 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VFS9u24622; Wed, 31 Jan 2001 09:28:09 -0600 Message-Id: <200101311528.f0VFS9u24622@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Drew Bloechl cc: rahul@rice.edu, linux-xfs@oss.sgi.com Subject: Re: XFS bug In-Reply-To: Message from Drew Bloechl of "Wed, 31 Jan 2001 03:27:45 PST." <20010131032744.A30113@perilith.com> Date: Wed, 31 Jan 2001 09:28:09 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The compiler is a good candidate here - we do have some issues still with later versions of gcc, it just has not made it to the top of the list for fixing yet. If you can try with an older gcc (the suggestion about kgcc from redhat 7 is a good one - it is what I am using) and let the list know if your problem goes away. We will eventually get to be compiler neutral in XFS, in the mean time if someone out there is feeling brave, they could try and work out what is wrong with XFS (or the compiler) when using a later gcc..... Steve > On Wed, Jan 31, 2001 at 03:29:41AM -0600, Rahul Jain wrote: > > On a CVS checkout of xfs-2.4-linux compiled with gcc 2.95.3 (in debian sid) > , > > with -march=k6 added to the compilation flags, I ran the fsstress test prog > ram, > > and after some time, recieved the following error: > > I'm pretty sure XFS still wants gcc 2.91.66. You must have hacked the > Makefile to get it to compile, right? > > I realize that that specific version of gcc isn't in Debian, however you > can take Redhat's RPM of kgcc from 7.0 and use alien to convert it to > deb. You can then do this in the toplevel Makefile: > > #comment out this line if compiling on RH 7.0 > #CC = $(CROSS_COMPILE)gcc -V egcs-2.91.66 > # AND uncomment the following line > CC = $(CROSS_COMPILE)kgcc > > I haven't had any problems with this setup yet (going on a few months > with /home on XFS). > > -- > Drew Bloechl > drew@cesspool.net > PGP key ID: 33855516 From owner-linux-xfs@oss.sgi.com Wed Jan 31 07:36:21 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 07:36:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:7693 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 07:36:05 -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 HAA26138 for ; Wed, 31 Jan 2001 07:35:06 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA655365; Wed, 31 Jan 2001 09:34:48 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA87844; Wed, 31 Jan 2001 09:34:48 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VFZf324681; Wed, 31 Jan 2001 09:35:41 -0600 Message-Id: <200101311535.f0VFZf324681@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: David Wragg cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: Message from David Wragg of "31 Jan 2001 12:36:53 GMT." Date: Wed, 31 Jan 2001 09:35:41 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing OK, I see what is going on here - and I think this could actually break regular XFS as well - if you use the loop device on a highmem machine. I will fix it in my 2.4.1 merge which should be out in cvs in a day or two. 2.4.1 is running with XFS, but I am not happy with what the kernel changes have done to performance. Steve > I'm testing XFS (from CVS as of sometime yesterday) on a machine with > 1GB memory and the kernel built with CONFIG_HIGHMEM. The kernel > contains code of my own which is provoking the problem, though it > isn't the root cause. > > What happens is that inside the kunmap in pagebuf_commit_write, the > check in kunmap_high() that the page is already mapped fails. > pagebuf_prepare_write isn't leaving the page mapped as it should (if > successful). > > I realize that XFS doesn't use generic_file_write itself, so this bug > doesn't affect XFS as is (pagebuf_generic_file_write correctly > kmaps/kunmaps). But since the pagebuf_{prepare,commit}_write are > exported to the rest of the kernel through the inode a_ops, it would > be nice if they followed the Linux semantics. > > > David Wragg > (please Cc: me on follow-ups, I'm not subscribed to this list) From owner-linux-xfs@oss.sgi.com Wed Jan 31 07:52:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 07:52:01 -0800 Received: from mail11.jump.net ([206.196.91.11]:38040 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 07:51:41 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f0VFpaF15227; Wed, 31 Jan 2001 09:51:36 -0600 (CST) Message-ID: <3A77C28E.10ED1975@sgi.com> Date: Wed, 31 Jan 2001 01:45:18 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Warner CC: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Adam Warner wrote: > > Hi Eric and the SGI XFS Mailing List, > And strangely the boot disk did nothing except turn the boot process over to > the HD MBR :-( *snip* > The boot disk contains: > initrd.img > lost+found > vmlinuz-2.4.0-SGI_XFS_PR *snip* Unfortunately, the kernel & initrd are probably too big for a floppy. You can take a look at it on another machine, but my guess is it's 100% full. We should probably add a caveat for this, or even disable the boot floppy creation for now... You can still use the CD you burned as a rescue disc, just type "linux rescue" at the boot: prompt and you'll be in single user mode. You can then mount up your partitions and try re-configuring lilo. You will probably need to create your own devices - take a look in /tmp and see what's there. > 1. Liked the SGI colour scheme and installer :-) Thanks. :) > 2. Your time zone selection missed out "Pacific Rim". It was still possible > to select Auckland (New Zealand) from the World Map. That's actually one for Red Hat, I guess - did you have this choice in their standard 7.0 installer? > 3. No ability to select 32 bit display modes for my 3dfx Voodoo3 3000. > > 4. On the first install I tested the screen resolution. Even though I was > able to see the message that the display mode was OK and click on it, the > installer display was then corrupted and I had to hard reset and start again > (BTW I chose 1152x854, 24 bit). Yes, the X configuration is known to be buggy... the same thing happened on my laptop. This is a snapshot of Red Hat's anaconda, so there are all sorts of bugs waiting to be discovered... -Eric From owner-linux-xfs@oss.sgi.com Wed Jan 31 08:25:51 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 08:25:32 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:54532 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 08:25:10 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id OAA11543; Wed, 31 Jan 2001 14:23:59 -0200 Date: Wed, 31 Jan 2001 12:34:46 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: David Wragg , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: <200101311535.f0VFZf324681@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 31 Jan 2001, Steve Lord wrote: > > OK, I see what is going on here - and I think this could actually > break regular XFS as well - if you use the loop device on a highmem > machine. I will fix it in my 2.4.1 merge which should be out in cvs > in a day or two. 2.4.1 is running with XFS, but I am not happy with > what the kernel changes have done to performance. Steve, Could you please describe what performance problems are going on? From owner-linux-xfs@oss.sgi.com Wed Jan 31 08:38:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 08:37:52 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:26967 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 08:37:32 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08688 for ; Wed, 31 Jan 2001 08:37:30 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA655135; Wed, 31 Jan 2001 10:36:12 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA67768; Wed, 31 Jan 2001 10:36:12 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VGb5n26720; Wed, 31 Jan 2001 10:37:05 -0600 Message-Id: <200101311637.f0VGb5n26720@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti cc: Steve Lord , David Wragg , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: Message from Marcelo Tosatti of "Wed, 31 Jan 2001 12:34:46 -0200." Date: Wed, 31 Jan 2001 10:37:05 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > > On Wed, 31 Jan 2001, Steve Lord wrote: > > > > > OK, I see what is going on here - and I think this could actually > > break regular XFS as well - if you use the loop device on a highmem > > machine. I will fix it in my 2.4.1 merge which should be out in cvs > > in a day or two. 2.4.1 is running with XFS, but I am not happy with > > what the kernel changes have done to performance. > > Steve, > > Could you please describe what performance problems are going on? > It is difficult to nail down the cause yet, but dbench has taken a significant hit (40%). Single file (bonnie) is comparable with 2.4.0, the dbench issue may be related to the throttling being placed on the ll_rw_block interface by Jens' changes. The problem with working out a bottleneck in dbench is it is such a random pile of stuff that you really cannot point a finger at any one thing. I need to go find some more deterministic measurements. The performance drop off is not limited to xfs though ext2 appears to suffer as well. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 31 08:44:41 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 08:44:22 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:25119 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 08:44: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 IAA05137 for ; Wed, 31 Jan 2001 08:43:07 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA655704; Wed, 31 Jan 2001 10:42:49 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA29026; Wed, 31 Jan 2001 10:42:49 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VGhgR26778; Wed, 31 Jan 2001 10:43:42 -0600 Message-Id: <200101311643.f0VGhgR26778@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: Message from Steve Lord of "Wed, 31 Jan 2001 10:37:05 CST." <200101311637.f0VGb5n26720@jen.americas.sgi.com> Date: Wed, 31 Jan 2001 10:43:42 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing To follow up on my own message - running some micro benchmarks, every single individual operation got faster, but dbench got slower..... Ho Hum. Steve > > > > On Wed, 31 Jan 2001, Steve Lord wrote: > > > > > > > > OK, I see what is going on here - and I think this could actually > > > break regular XFS as well - if you use the loop device on a highmem > > > machine. I will fix it in my 2.4.1 merge which should be out in cvs > > > in a day or two. 2.4.1 is running with XFS, but I am not happy with > > > what the kernel changes have done to performance. > > > > Steve, > > > > Could you please describe what performance problems are going on? > > > > > It is difficult to nail down the cause yet, but dbench has taken a > significant hit (40%). Single file (bonnie) is comparable with 2.4.0, the > dbench issue may be related to the throttling being placed on the > ll_rw_block interface by Jens' changes. The problem with working out > a bottleneck in dbench is it is such a random pile of stuff that > you really cannot point a finger at any one thing. I need to go > find some more deterministic measurements. > > The performance drop off is not limited to xfs though ext2 appears > to suffer as well. > > Steve > From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:04:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:03:52 -0800 Received: from perninha.conectiva.com.br ([200.250.58.156]:58372 "EHLO perninha.conectiva.com.br") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:03:23 -0800 Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22]) by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id PAA11791; Wed, 31 Jan 2001 15:02:56 -0200 Date: Wed, 31 Jan 2001 13:13:49 -0200 (BRST) From: Marcelo Tosatti X-Sender: marcelo@freak.distro.conectiva To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: <200101311643.f0VGhgR26778@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 Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Does your benchmarks make something hit swap? On Wed, 31 Jan 2001, Steve Lord wrote: > > To follow up on my own message - running some micro benchmarks, every single > individual operation got faster, but dbench got slower..... > > Ho Hum. > > Steve > > > > > > > > On Wed, 31 Jan 2001, Steve Lord wrote: > > > > > > > > > > > OK, I see what is going on here - and I think this could actually > > > > break regular XFS as well - if you use the loop device on a highmem > > > > machine. I will fix it in my 2.4.1 merge which should be out in cvs > > > > in a day or two. 2.4.1 is running with XFS, but I am not happy with > > > > what the kernel changes have done to performance. > > > > > > Steve, > > > > > > Could you please describe what performance problems are going on? > > > > > > > > > It is difficult to nail down the cause yet, but dbench has taken a > > significant hit (40%). Single file (bonnie) is comparable with 2.4.0, the > > dbench issue may be related to the throttling being placed on the > > ll_rw_block interface by Jens' changes. The problem with working out > > a bottleneck in dbench is it is such a random pile of stuff that > > you really cannot point a finger at any one thing. I need to go > > find some more deterministic measurements. > > > > The performance drop off is not limited to xfs though ext2 appears > > to suffer as well. > > > > Steve > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:30:52 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:30:41 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:55055 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:30:31 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O14r-0000tq-00; Wed, 31 Jan 2001 18:29:53 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O14n-0002LF-00; Wed, 31 Jan 2001 18:29:49 +0100 Date: Wed, 31 Jan 2001 18:29:49 +0100 From: Jens Axboe To: Steve Lord Cc: Marcelo Tosatti , David Wragg , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131182949.O508@suse.de> References: <200101311637.f0VGb5n26720@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101311637.f0VGb5n26720@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jan 31, 2001 at 10:37:05AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Steve Lord wrote: > It is difficult to nail down the cause yet, but dbench has taken a > significant hit (40%). Single file (bonnie) is comparable with 2.4.0, the > dbench issue may be related to the throttling being placed on the > ll_rw_block interface by Jens' changes. The problem with working out > a bottleneck in dbench is it is such a random pile of stuff that > you really cannot point a finger at any one thing. I need to go > find some more deterministic measurements. > > The performance drop off is not limited to xfs though ext2 appears > to suffer as well. You can easily disable the throttling of locked buffers by just defining blk_started_io and blk_finished_io to do nothing. What disk are you using, and how much RAM in the machine? Also, is dbench the only bench affected? -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:31:52 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:31:41 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:56335 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:31:34 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O16H-0000ua-00; Wed, 31 Jan 2001 18:31:21 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O16D-0002Ls-00; Wed, 31 Jan 2001 18:31:17 +0100 Date: Wed, 31 Jan 2001 18:31:17 +0100 From: Jens Axboe To: Steve Lord Cc: Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131183117.P508@suse.de> References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101311643.f0VGhgR26778@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jan 31, 2001 at 10:43:42AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Steve Lord wrote: > > To follow up on my own message - running some micro benchmarks, every single > individual operation got faster, but dbench got slower..... Dbench being slower in 2.4.1 vs 2.4.0 would be quite normal, and I wouldn't be alarmed if it's the only one disturbed by this. The easy way to get screamer dbench numbers is to completely ignore latency and finish one process I/O at the time only. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:37:41 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:37:22 -0800 Received: from Cantor.suse.de ([213.95.15.193]:36622 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Wed, 31 Jan 2001 09:37:18 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B6AF11E1FF; Wed, 31 Jan 2001 18:37:16 +0100 (MET) Date: Wed, 31 Jan 2001 18:37:12 +0100 From: Andi Kleen To: Jens Axboe Cc: Steve Lord , Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131183712.A31126@gruyere.muc.suse.de> References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010131183117.P508@suse.de>; from axboe@suse.de on Wed, Jan 31, 2001 at 06:31:17PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31, 2001 at 06:31:17PM +0100, Jens Axboe wrote: > On Wed, Jan 31 2001, Steve Lord wrote: > > > > To follow up on my own message - running some micro benchmarks, every single > > individual operation got faster, but dbench got slower..... > > Dbench being slower in 2.4.1 vs 2.4.0 would be quite normal, and > I wouldn't be alarmed if it's the only one disturbed by this. The > easy way to get screamer dbench numbers is to completely ignore > latency and finish one process I/O at the time only. This sounds like it would be interesting to modify dbench to log average running times for individual processes. Then such latency changes could be catched. -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:38:52 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:38:43 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:14456 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:38:26 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08238 for ; Wed, 31 Jan 2001 09:38:25 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA656971; Wed, 31 Jan 2001 11:37:08 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA99718; Wed, 31 Jan 2001 11:37:08 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VHc0Z32271; Wed, 31 Jan 2001 11:38:01 -0600 Message-Id: <200101311738.f0VHc0Z32271@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jens Axboe cc: Steve Lord , Marcelo Tosatti , David Wragg , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-Reply-To: Message from Jens Axboe of "Wed, 31 Jan 2001 18:29:49 +0100." <20010131182949.O508@suse.de> Date: Wed, 31 Jan 2001 11:38:00 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Wed, Jan 31 2001, Steve Lord wrote: > > It is difficult to nail down the cause yet, but dbench has taken a > > significant hit (40%). Single file (bonnie) is comparable with 2.4.0, the > > dbench issue may be related to the throttling being placed on the > > ll_rw_block interface by Jens' changes. The problem with working out > > a bottleneck in dbench is it is such a random pile of stuff that > > you really cannot point a finger at any one thing. I need to go > > find some more deterministic measurements. > > > > The performance drop off is not limited to xfs though ext2 appears > > to suffer as well. > > You can easily disable the throttling of locked buffers by just > defining blk_started_io and blk_finished_io to do nothing. What > disk are you using, and how much RAM in the machine? This is a Segate ST39175LW - nothing to exciting. I am actually now not sure if the throttling code really has too much to do with it. In answer to your next message, yes dbench appears to be the only thing I can find which really suffers, so I am not too worried. Currently I am working my way though a deadlock I managed to introduce with some other changes, then I will be pushing the 2.4.1 version out onto the net. Steve > > Also, is dbench the only bench affected? > > -- > Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:40:22 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:40:12 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:61199 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:39:51 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O1Dy-0000wt-00; Wed, 31 Jan 2001 18:39:18 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O1Dv-0002Ni-00; Wed, 31 Jan 2001 18:39:15 +0100 Date: Wed, 31 Jan 2001 18:39:15 +0100 From: Jens Axboe To: Steve Lord Cc: Marcelo Tosatti , David Wragg , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131183915.R508@suse.de> References: <200101311738.f0VHc0Z32271@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101311738.f0VHc0Z32271@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jan 31, 2001 at 11:38:00AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Steve Lord wrote: > > You can easily disable the throttling of locked buffers by just > > defining blk_started_io and blk_finished_io to do nothing. What > > disk are you using, and how much RAM in the machine? > > This is a Segate ST39175LW - nothing to exciting. I am actually > now not sure if the throttling code really has too much to do with it. Depends on the RAM in the machine, but I don't think the throttling is the problem either. > In answer to your next message, yes dbench appears to be the only > thing I can find which really suffers, so I am not too worried. Fine -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:40:42 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:40:22 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:61455 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:40:06 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O1EP-0000wx-00; Wed, 31 Jan 2001 18:39:45 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O1EL-0002Nn-00; Wed, 31 Jan 2001 18:39:41 +0100 Date: Wed, 31 Jan 2001 18:39:41 +0100 From: Jens Axboe To: Andi Kleen Cc: Steve Lord , Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131183941.S508@suse.de> References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010131183712.A31126@gruyere.muc.suse.de>; from ak@suse.de on Wed, Jan 31, 2001 at 06:37:12PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Andi Kleen wrote: > > Dbench being slower in 2.4.1 vs 2.4.0 would be quite normal, and > > I wouldn't be alarmed if it's the only one disturbed by this. The > > easy way to get screamer dbench numbers is to completely ignore > > latency and finish one process I/O at the time only. > > This sounds like it would be interesting to modify dbench to log average > running times for individual processes. Then such latency changes could > be catched. Indeed, this would make it an even better disk benchmark. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:44:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:43:52 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:44593 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:43:51 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA14053 for ; Wed, 31 Jan 2001 09:42:50 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA655498; Wed, 31 Jan 2001 11:42:32 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA07562; Wed, 31 Jan 2001 11:42:32 -0600 (CST) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f0VHhPd32287; Wed, 31 Jan 2001 11:43:25 -0600 Message-Id: <200101311743.f0VHhPd32287@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen cc: marcelo@conectiva.com.br, linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> Comments: In-reply-to Andi Kleen message dated "Wed, 31 Jan 2001 18:37:12 +0100." Date: Wed, 31 Jan 2001 11:43:25 -0600 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > On Wed, Jan 31, 2001 at 06:31:17PM +0100, Jens Axboe wrote: > > On Wed, Jan 31 2001, Steve Lord wrote: > > > > > > To follow up on my own message - running some micro benchmarks, every sin > gle > > > individual operation got faster, but dbench got slower..... > > > > Dbench being slower in 2.4.1 vs 2.4.0 would be quite normal, and > > I wouldn't be alarmed if it's the only one disturbed by this. The > > easy way to get screamer dbench numbers is to completely ignore > > latency and finish one process I/O at the time only. > > This sounds like it would be interesting to modify dbench to log average > running times for individual processes. Then such latency changes could > be catched. One noticable change in dbench is that in 2.4.0 - and for a long time prior to that, the individual dbench programs used to complete at widely differing times, now they pretty much all get a fair share of the system and we end up with them all running for about the same time. I suppose this would mean more memory load on the system for the whole duration of the run, where before the longer running threads got to run under lighter load once the other threads had finished. This would probably account for the slowdown. Steve > > > -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 31 09:49:52 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 09:49:42 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:784 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 09:49:31 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O1Ne-0000zL-00; Wed, 31 Jan 2001 18:49:18 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O1Na-0002R9-00; Wed, 31 Jan 2001 18:49:14 +0100 Date: Wed, 31 Jan 2001 18:49:14 +0100 From: Jens Axboe To: Steve Lord Cc: Andi Kleen , marcelo@conectiva.com.br, linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131184914.T508@suse.de> References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> <200101311743.f0VHhPd32287@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200101311743.f0VHhPd32287@jen.americas.sgi.com>; from lord@sgi.com on Wed, Jan 31, 2001 at 11:43:25AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Steve Lord wrote: > One noticable change in dbench is that in 2.4.0 - and for a long time > prior to that, the individual dbench programs used to complete at widely > differing times, now they pretty much all get a fair share of the system > and we end up with them all running for about the same time. I suppose this > would mean more memory load on the system for the whole duration of the run, > where before the longer running threads got to run under lighter load once > the other threads had finished. > > This would probably account for the slowdown. This is exactly the reason as I outlined -- letting them complete without paying too much attention to latencies of individual dbench threads gives you much better results. dbench is a good benchmark, you just have to keep in mind what it measures and not just eat the numbers up raw ;-) -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 10:20:02 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 10:19:53 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41229 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 10:19:36 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA03247 for ; Wed, 31 Jan 2001 10:28:42 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA03743 for ; Wed, 31 Jan 2001 10:14:25 -0800 (PST) Message-ID: <3A7856E5.F91FBA30@sgi.com> Date: Wed, 31 Jan 2001 10:18:13 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> <200101311743.f0VHhPd32287@jen.americas.sgi.com> <20010131184914.T508@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Jens Axboe wrote: > > On Wed, Jan 31 2001, Steve Lord wrote: > > One noticable change in dbench is that in 2.4.0 - and for a long time > > prior to that, the individual dbench programs used to complete at widely > > differing times, now they pretty much all get a fair share of the system > > and we end up with them all running for about the same time. I suppose this > > would mean more memory load on the system for the whole duration of the run, > > where before the longer running threads got to run under lighter load once > > the other threads had finished. > > > > This would probably account for the slowdown. Another datapoint. On a 2CPU 64MB system dbench (48 clients) would yield about 3.5-4.5 MB/sec on 2.4.0 ... with 2.4.1pre9 the same setup would yield about 5+ MB/sec. The tests were run on ext2. I too noticed that the individual threads were completing at about the same time in 2.4.1pre9, as opposed to some threads finishing really early in 2.4.0. > > This is exactly the reason as I outlined -- letting them complete > without paying too much attention to latencies of individual dbench > threads gives you much better results. > > dbench is a good benchmark, you just have to keep in mind what it > measures and not just eat the numbers up raw ;-) -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jan 31 11:17:12 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 11:17:02 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:63534 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 11:16:56 -0800 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA01820 for ; Wed, 31 Jan 2001 11:16:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA658048 for ; Wed, 31 Jan 2001 13:15:39 -0600 (CST) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA29304 for ; Wed, 31 Jan 2001 13:15:39 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f0VJGVR04461; Wed, 31 Jan 2001 13:16:31 -0600 Message-Id: <200101311916.f0VJGVR04461@jen.americas.sgi.com> Date: Wed, 31 Jan 2001 13:16:31 -0600 Subject: TAKE - fix use of kmap and kunmap in xfs address space ops To: unlisted-recipients:; (no To-header on input) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing XFS was not leaving highmem pages kmapped after the prepare_write call. This reworks when we map and unmap pages in pagebuf to give the expected behavior. Probably will not affect people using xfs except maybe with loop devices on highmem systems. Date: Wed Jan 31 11:14:05 PST 2001 Workarea: 128.162.184.86:/src/lord/linux-jen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:84534a linux/fs/pagebuf/page_buf_io.c - 1.47 - Do the correct thing with prepare_write and commit_write and kmapping pages. From owner-linux-xfs@oss.sgi.com Wed Jan 31 12:17:53 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 12:17:33 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:7443 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Wed, 31 Jan 2001 12:17:08 -0800 Received: (qmail 14728 invoked from network); 31 Jan 2001 20:17:02 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Jan 2001 20:17:02 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Aldert Zomer cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page In-reply-to: Your message of "Wed, 31 Jan 2001 13:57:26 BST." <3A780BB6.2F6F3054@biol.rug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 07:17:02 +1100 Message-ID: <6614.980972222@ocs3.ocs-net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 31 Jan 2001 13:57:26 +0100, Aldert Zomer wrote: >I'm using XFS on a SMP machine with 2 GB, also built with >CONFIG_HIGHMEM. I'm receiving these errors after the machine has been up >for a while. I didn't have this problem with the standard 2.4.0 kernel >or with a 2.2.18 kernel. Or my memory is suddenly faulty, or perhaps >there is a problem with the 2.4.0-XFS kernel. Can anyone help me here? > >It's a redhat7 box, all the latest patches applied, 2.4.0-XFS kernel >from cvs (from 30 januari) build with kgcc. > >snippet from /var/log/messages: > >Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, >but trying to continue >Jan 30 17:01:49 molgen kernel: Uhhuh. NMI received. Dazed and confused, >but trying to continue >Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with >your RAM chips >Jan 30 17:01:49 molgen kernel: You probably have a hardware problem with >your RAM chips > >I've placed /var/log/dmesg online for some more information about my >system: > >http://molgen.biol.rug.nl/dmesg I bounced this problem off Ingo Molnar and Maciej W. Rozycki, who look after io-apic and nmi code. Maciej said I've looked at the log and it seems to be a ServerWorks chipset, unfortunately. The manufacturer is hard to cooperate -- they declare they want to support Linux, but they are much worried of the competition and do not provide documentation. I've already asked them about the IRQ 0 routing problem you may see in the log -- we must route it through the 8259A to make it work at all. They answered an NDA is required to get any docs. With this in mind I can only assume the guy has faulty RAM in his system and a NMI reports it. Note that certain chipsest use the NMI to report ECC-corrected errors as well. We don't have a real memory error handler in Linux, unfortunately, although there is a patch for certain chipsets available. They confirm my suspicion that the problem is probably not XFS related. It is more likely to be memory or the chipset. BTW, is this a ServerWorks chipset? Transient memory problems are notoriously sensitive to data access patterns, slightly faulty memory will work under Windows but fail under Linux because we drive it harder. Adding XFS will change the data access patterns. From owner-linux-xfs@oss.sgi.com Wed Jan 31 13:14:58 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 13:14:49 -0800 Received: from ns.virtualhost.dk ([195.184.98.160]:4113 "EHLO virtualhost.dk") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 13:14:27 -0800 Received: from burns.home.kernel.dk ([192.168.0.2]) by virtualhost.dk with esmtp (Exim 3.16 #1) id 14O4a2-0003Ik-00; Wed, 31 Jan 2001 22:14:18 +0100 Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian)) id 14O4Zx-0003Ta-00; Wed, 31 Jan 2001 22:14:13 +0100 Date: Wed, 31 Jan 2001 22:14:13 +0100 From: Jens Axboe To: Rajagopal Ananthanarayanan Cc: linux-xfs@oss.sgi.com Subject: Re: pagebuf_prepare_write doesn't kmap the page Message-ID: <20010131221413.B12971@suse.de> References: <200101311643.f0VGhgR26778@jen.americas.sgi.com> <20010131183117.P508@suse.de> <20010131183712.A31126@gruyere.muc.suse.de> <200101311743.f0VHhPd32287@jen.americas.sgi.com> <20010131184914.T508@suse.de> <3A7856E5.F91FBA30@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A7856E5.F91FBA30@sgi.com>; from ananth@sgi.com on Wed, Jan 31, 2001 at 10:18:13AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, Jan 31 2001, Rajagopal Ananthanarayanan wrote: > Another datapoint. On a 2CPU 64MB system dbench (48 clients) would > yield about 3.5-4.5 MB/sec on 2.4.0 ... with 2.4.1pre9 the same > setup would yield about 5+ MB/sec. The tests were run on ext2. > > I too noticed that the individual threads were completing at about > the same time in 2.4.1pre9, as opposed to some threads finishing > really early in 2.4.0. This just goes to show that the free request batching done with blk-14 really helps, so even though we are much more latency oriented there are still setups where 2.4.1-xx beats the pants of 2.4.0. Yet another small optimization that helps at least here over the approach that Linus wanted (...), is this: --- /opt/kernel/linux-2.4.1/drivers/block/ll_rw_blk.c Tue Jan 30 13:32:10 2001 +++ drivers/block/ll_rw_blk.c Wed Jan 31 18:09:59 2001 @@ -628,11 +628,19 @@ && atomic_read(&queued_sectors) < low_queued_sectors) wake_up(&blk_buffers_wait); + if (!list_empty(&q->request_freelist[rw])) { + blk_refill_freelist(q, rw); + list_add(&req->table, &q->request_freelist[rw]); + if (waitqueue_active(&q->wait_for_request)) + wake_up_nr(&q->wait_for_request, 2); + return; + } + /* - * Add to pending free list and batch wakeups + * free list is empty, add to pending free list and + * batch wakeups */ list_add(&req->table, &q->pending_freelist[rw]); - if (++q->pending_free[rw] >= batch_requests) { int wake_up = q->pending_free[rw]; blk_refill_freelist(q, rw); which makes sure that we observe the batch count all the time, but trickles wakeups if X sleepers didn't eat all the requests. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Wed Jan 31 15:41:19 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 15:41:10 -0800 Received: from ns5.novsvcs.net ([192.208.44.111]:61197 "EHLO novalfsmtp2.novsvcs.net") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 15:40:55 -0800 Received: from pp-rafiki-chbs.cp.chbs ([168.246.161.139]) by novalfsmtp2.novsvcs.net (8.10.2/8.9.3) with ESMTP id f0VNfTY20440 for ; Wed, 31 Jan 2001 18:41:30 -0500 X-Authentication-Warning: novalfsmtp2.novsvcs.net: Host [168.246.161.139] claimed to be pp-rafiki-chbs.cp.chbs Received: from pp-banzai-chbs.cp.chbs (pp-banzai-chbs.cp.chbs [168.246.161.82]) by pp-rafiki-chbs.cp.chbs (Build 101 8.9.3/NT-8.9.3) with ESMTP id AAA01054 for ; Thu, 01 Feb 2001 00:40:49 +0100 From: kenneth.leung@syngenta.com Received: by pp-banzai-chbs with Internet Mail Service (5.5.2650.21) id <1BGRJWQX>; Thu, 1 Feb 2001 00:40:49 +0100 Message-ID: To: linux-xfs@oss.sgi.com Subject: /dev/cdrom missing... Date: Thu, 1 Feb 2001 00:40:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hello, Our company has been testing SGI's XFS solution for Linux on our Intel cluster machines. We are happy with the results so far, which allow us to store database files exceeding ext2's standard 2GB limit. However, after installing the 0.9 pre-release version we noticed that the /dev/cdrom device file was missing. This is strange because we installed Linux with the CDs burned from images provided on SGI's site, and upon booting the /dev/hdc device is recognized as our Toshiba CDROM. But after the kernel is booted and we log in, neither the /dev/hdc file or /dev/cdrom file exists. This is preventing us from mounting CDs and installing more software. Can you tell us if this is a known issue, and if there is a fix being developed? Thank you, Ken ******************************************* Kenneth Leung IT Administrator Syngenta - La Jolla, California kenneth.leung@syngenta.com (858) 812-1223 ******************************************* From owner-linux-xfs@oss.sgi.com Wed Jan 31 15:46:19 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 15:46:00 -0800 Received: from mail15.jump.net ([206.196.91.15]:63713 "EHLO mail15.jump.net") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 15:45:55 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail15.jump.net (8.10.2/) with ESMTP id f0VNjpN24910; Wed, 31 Jan 2001 17:45:51 -0600 (CST) Message-ID: <3A78A3B4.D8FD8BAE@sgi.com> Date: Wed, 31 Jan 2001 17:45:56 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: kenneth.leung@syngenta.com CC: linux-xfs@oss.sgi.com Subject: Re: /dev/cdrom missing... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing The system uses devfs by default - you should have /dev/cdroms/cdrom0 etc... /dev/cdroms will appear after you load the ide_cd module. Please see the caveats page at http://oss.sgi.com/projects/xfs/installcavs.html for information on devfs and other issues. -Eric kenneth.leung@syngenta.com wrote: > > Hello, > > Our company has been testing SGI's XFS solution for Linux on our Intel > cluster machines. We are happy with the results so far, which allow us to > store database files exceeding ext2's standard 2GB limit. However, after > installing the 0.9 pre-release version we noticed that the /dev/cdrom device > file was missing. This is strange because we installed Linux with the CDs > burned from images provided on SGI's site, and upon booting the /dev/hdc > device is recognized as our Toshiba CDROM. But after the kernel is booted > and we log in, neither the /dev/hdc file or /dev/cdrom file exists. This is > preventing us from mounting CDs and installing more software. > > Can you tell us if this is a known issue, and if there is a fix being > developed? > > Thank you, > Ken From owner-linux-xfs@oss.sgi.com Wed Jan 31 18:15:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 18:14:51 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:39546 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 18:14:28 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 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 SAA00036 for ; Wed, 31 Jan 2001 18:14:27 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA01076 for ; Wed, 31 Jan 2001 18:13:09 -0800 (PST) Date: Wed, 31 Jan 2001 18:14:08 -0800 (PST) From: Tom Duffy To: Subject: vmware under pre-release 0.9 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Has anyone gotten vmware to work under pre-release 0.9... when I run vmware-config.pl, I get the following error: *snip* What is the location of the directory of C header files that match your running kernel? [/usr/src/linux-2.4/include] Extracting the sources of the vmmon module. Building the vmmon module. make: Entering directory `/tmp/vmware-config3/vmmon-only' make[1]: Entering directory `/tmp/vmware-config3/vmmon-only' make[2]: Entering directory `/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' make[2]: Leaving directory `/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' make[2]: Entering directory `/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' /tmp/ccIEbMf3.s: Assembler messages: /tmp/ccIEbMf3.s:8: Warning: Ignoring changed section attributes for .modinfo make[2]: Leaving directory `/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' make[1]: Leaving directory `/tmp/vmware-config3/vmmon-only' make: Leaving directory `/tmp/vmware-config3/vmmon-only' Unable to make a vmmon module that can be loaded in the running kernel: /tmp/vmware-config3/vmmon.o: unresolved symbol irq_stat There is probably a light difference of kernel configuration between the set of C header files you specified and your running kernel. You may want to rebuild a kernel based on that directory, or specify another directory. For more information on how to troubleshoot module-related problems, please havea look at "http://www.vmware.com/download/modules/modules.html". Execution aborted. *snip* this works fine under 2.4.0 kernel. (at least this is what vmware claims :) -tduffy From owner-linux-xfs@oss.sgi.com Wed Jan 31 18:54:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 18:54:02 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22087 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 18:53:38 -0800 Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA00395 for ; Wed, 31 Jan 2001 19:02:42 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI) id NAA08167; Thu, 1 Feb 2001 13:52:48 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Tom Duffy cc: linux-xfs@oss.sgi.com Subject: Re: vmware under pre-release 0.9 In-reply-to: Your message of "Wed, 31 Jan 2001 18:14:08 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 13:52:14 +1100 Message-ID: <11308.980995934@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing On Wed, 31 Jan 2001 18:14:08 -0800 (PST), Tom Duffy wrote: >when I run vmware-config.pl, I get the following error: >/tmp/ccIEbMf3.s:8: Warning: Ignoring changed section attributes for >.modinfo Ignore, only a warning. Patch already sent to Linus. >make: Leaving directory `/tmp/vmware-config3/vmmon-only' >Unable to make a vmmon module that can be loaded in the running kernel: >/tmp/vmware-config3/vmmon.o: unresolved symbol irq_stat The code looks OK. I suspect you are compiling on a machine running 2.2 or an old 2.3 kernel. irq_stat was not defined until July 2000, between 2.4.0-test5 and 2.4.0-test6. From owner-linux-xfs@oss.sgi.com Wed Jan 31 19:22:11 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 19:22:01 -0800 Received: from drone1-svc-skyt.qsi.net.nz ([202.89.128.1]:63246 "HELO drone1.qsi.net.nz") by oss.sgi.com with SMTP id ; Wed, 31 Jan 2001 19:21:38 -0800 Received: (qmail 72403 invoked by uid 0); 1 Feb 2001 03:21:35 -0000 Received: from unknown (HELO adam) ([202.89.144.61]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2001 03:21:35 -0000 From: "Adam Warner" To: Subject: RE: xfs installer (SGI Pre-Release ISO) Date: Thu, 1 Feb 2001 16:22:02 +1200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A77C28E.10ED1975@sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Hi Eric and all, BTW since I now know about your installer caveats I see I was using the wrong (original) RH7.0 install CDs (for the procedure I used with your pre-release ISO). > You can still use the CD you burned as a rescue disc, just type "linux > rescue" at the boot: prompt and you'll be in single user mode. You can > then mount up your partitions and try re-configuring lilo. > You will probably need to create your own devices - take a look in /tmp > and see what's there. Thanks. Knowing how to create my own devices is beyond me at this stage. I was not able to properly mount /dev/hde1 and received this error message: mount failed: block device required. I was however able to mount /dev/hde1 on the loopback device. This allowed me to access the partition. Unfortunately lilo would not accept the configuration info because /dev/hde1 was not "properly" mounted. /tmp contained: cdrom, loop, modules.conf (just a link for the ||port), and syslog. So at this stage I'll probably have to leave my attempt to install the pre-release ISO and await an ext2 conversion procedure or utility. > > 2. Your time zone selection missed out "Pacific Rim". It was still possible > > to select Auckland (New Zealand) from the World Map. > That's actually one for Red Hat, I guess - did you have this choice in > their standard 7.0 installer? I am almost certain the original RH7.0 install CD gives me this option (the option is also listed in the LHS help text of the installer). > This is a snapshot of Red Hat's anaconda, so there are all sorts of bugs > waiting to be discovered... OK. Best wishes for the development. Regards, Adam From owner-linux-xfs@oss.sgi.com Wed Jan 31 19:24:01 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 19:23:41 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:2415 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 19:23:34 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA11681 for ; Wed, 31 Jan 2001 19:22:35 -0800 (PST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA18620; Wed, 31 Jan 2001 19:22:11 -0800 (PST) Date: Wed, 31 Jan 2001 19:23:10 -0800 (PST) From: Tom Duffy To: Keith Owens cc: Subject: Re: vmware under pre-release 0.9 In-Reply-To: <11308.980995934@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing > The code looks OK. I suspect you are compiling on a machine running > 2.2 or an old 2.3 kernel. irq_stat was not defined until July 2000, > between 2.4.0-test5 and 2.4.0-test6. I am on a machine that had the pre-release 0.9 redhat installer install a fresh copy of redhat on it. it is running 2.4.0 with 2.4.0 headers. I have also tried using vmware on a 2.4 kernel installed after redhat was isntalled. -tduffy From owner-linux-xfs@oss.sgi.com Wed Jan 31 20:06:31 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 20:06:11 -0800 Received: from mail11.jump.net ([206.196.91.11]:31948 "EHLO mail11.jump.net") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 20:05:47 -0800 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f1145hi23447; Wed, 31 Jan 2001 22:05:43 -0600 (CST) Message-ID: <3A78DDE2.C7C36D0C@sgi.com> Date: Wed, 31 Jan 2001 21:54:10 -0600 From: Eric Sandeen X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Warner CC: linux-xfs@oss.sgi.com Subject: Re: xfs installer (SGI Pre-Release ISO) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Adam Warner wrote: > Thanks. Knowing how to create my own devices is beyond me at this stage. I > was not able to properly mount /dev/hde1 and received this error message: > mount failed: block device required. See the installer caveats at http://oss.sgi.com/projects/xfs/pr_installer.html for hints on making devices... It's not too bad. Use "linux rescue" off the installer CD. Check /proc/devices to make sure you have IDE support at all (you should see "hd" or "ide" - I'm not sure...). Insert modules as necessary (ide-mod, ide-disk, ide-cd...). You can make devices as follows: cd /tmp mknod hda b 3 (i.e. mknod hda1 b 3) mknod hda b 3 (if you have /boot) mount hda /mnt/A mount hda /mnt/A/boot chroot /mnt/A Now you should be able to do some lilo work... if you need to recreate the initial ramdisk: /sbin/mkinitrd /boot/initrd-2.4.0-SGI_XFS_PR.img 2.4.0-SGI_XFS_PR vi /etc/lilo.conf add to the correct kernel entry: initrd=/boot/initrd-2.4.0-SGI_XFS_PR.img /sbin/lilo -v When you're done: exit (out of chrooted shell) umount /mnt/A/boot umount /mnt/A From owner-linux-xfs@oss.sgi.com Wed Jan 31 20:20:32 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 20:20:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:64887 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 20:19:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA15950 for ; Wed, 31 Jan 2001 20:18:49 -0800 (PST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA04780 for linux-xfs@oss.sgi.com; Thu, 1 Feb 2001 15:18:31 +1100 (EST) Date: Thu, 1 Feb 2001 15:18:31 +1100 (EST) From: Andrew Gildfind Message-Id: <200102010418.PAA04780@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsqa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:84627a Date: Wed Jan 31 20:18:48 PST 2001 Workarea: snort:/home/ajag/isms/slinx Author: ajag The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfstests/041 - 1.2 cmd/xfstests/042 - 1.2 - Filter Electric Fence spam. cmd/xfstests/common.config - 1.2 - Add snowy to config From owner-linux-xfs@oss.sgi.com Wed Jan 31 20:49:32 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 20:49:22 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:28796 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 20:49:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA18157 for ; Wed, 31 Jan 2001 20:48:00 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA43001 for linux-xfs@oss.sgi.com; Thu, 1 Feb 2001 15:47:41 +1100 (EST) Date: Thu, 1 Feb 2001 15:47:41 +1100 (EST) From: Timothy Shimmin Message-Id: <200102010447.PAA43001@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - EA/ACL syscalls Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing This changes the syscalls files in the kernel and userspace so that they only support i386 and ia64 for EA/ACL. Will need some help/access to test the ia64 cases. If other arch's are to be supported for EA and ACL syscalls then libattr, libacl, and the appropriate entry.S and unistd.h files need to be updated together. We have no easy-access/pressing-need to test other arch's. --Tim cleanup attr/acl syscalls Modid: 2.4.x-xfs:slinx:84630a Date: Wed Jan 31 20:38:20 PST 2001 Workarea: snort:/diskb/build4/tes/slinx-xfs-acl Author: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/acl/libacl/acl.c - 1.4 cmd/attr/libattr/attr.c - 1.2 linux/arch/alpha/kernel/entry.S - 1.17 linux/arch/arm/kernel/calls.S - 1.14 linux/arch/ia64/ia32/ia32_entry.S - 1.10 linux/arch/ia64/kernel/entry.S - 1.11 linux/arch/ia64/kernel/ivt.S - 1.9 linux/arch/m68k/kernel/entry.S - 1.13 linux/arch/mips/kernel/irix5sys.h - 1.6 linux/arch/mips/kernel/syscalls.h - 1.9 linux/arch/mips64/kernel/scall_64.S - 1.7 linux/arch/ppc/kernel/misc.S - 1.24 linux/arch/s390/kernel/entry.S - 1.5 linux/arch/sh/kernel/entry.S - 1.15 linux/arch/sparc/kernel/systbls.S - 1.16 linux/arch/sparc64/kernel/systbls.S - 1.19 linux/include/asm-alpha/unistd.h - 1.13 linux/include/asm-arm/unistd.h - 1.14 linux/include/asm-i386/unistd.h - 1.15 linux/include/asm-ia64/unistd.h - 1.10 linux/include/asm-m68k/unistd.h - 1.10 linux/include/asm-mips/unistd.h - 1.9 linux/include/asm-mips64/unistd.h - 1.7 linux/include/asm-ppc/unistd.h - 1.13 linux/include/asm-s390/unistd.h - 1.5 linux/include/asm-sh/unistd.h - 1.11 linux/include/asm-sparc/unistd.h - 1.11 linux/include/asm-sparc64/unistd.h - 1.13 From owner-linux-xfs@oss.sgi.com Wed Jan 31 21:06:32 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 21:06:22 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:333 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 21:06:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08321 for ; Wed, 31 Jan 2001 21:15:12 -0800 (PST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA45237 for linux-xfs@oss.sgi.com; Thu, 1 Feb 2001 16:04:48 +1100 (EST) Date: Thu, 1 Feb 2001 16:04:48 +1100 (EST) From: Andrew Gildfind Message-Id: <200102010504.QAA45237@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsqa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Modid: 2.4.x-xfs:slinx:84632a Date: Wed Jan 31 21:05:22 PST 2001 Workarea: snort:/home/ajag/isms/slinx Author: ajag The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs cmd/xfstests/src/fill2fs - 1.2 - Don't run xfsdb if we're not root. From owner-linux-xfs@oss.sgi.com Wed Jan 31 22:10:23 2001 Received: by oss.sgi.com id ; Wed, 31 Jan 2001 22:10:02 -0800 Received: from mclean.mail.mindspring.net ([207.69.200.57]:4912 "EHLO mclean.mail.mindspring.net") by oss.sgi.com with ESMTP id ; Wed, 31 Jan 2001 22:09:56 -0800 Received: from COM (user-38ld6ig.dialup.mindspring.com [209.86.154.80]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with SMTP id BAA16225; Thu, 1 Feb 2001 01:09:44 -0500 (EST) From: jtrostel@mindspring.com Message-Id: <200102010609.BAA16225@mclean.mail.mindspring.net> To: Tom Duffy cc: linux-xfs@oss.sgi.com Subject: re: vmware under pre-release 0.9 Date: Thu, 1 Feb 2001 1:08:00 -0500 Mime-Version: 1.0 X-Mailer: MultiMail PRO (c) 1998-2000 3.1, Actual Software Corp. X-Sender: jtrostel@mindspring.com Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Which build of vmware are you using? Vmware works for me with an SGI-XFS kernel from Monday of this week. I am using build 7(?)99 of Vmware (the most recent one available from their web site) Tom Duffy wrote: __________ >Has anyone gotten vmware to work under pre-release 0.9... > >when I run vmware-config.pl, I get the following error: > >*snip* > >What is the location of the directory of C header files that match your >running kernel? [/usr/src/linux-2.4/include] > >Extracting the sources of the vmmon module. > >Building the vmmon module. > >make: Entering directory `/tmp/vmware-config3/vmmon-only' >make[1]: Entering directory `/tmp/vmware-config3/vmmon-only' >make[2]: Entering directory >`/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' >make[2]: Leaving directory >`/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' >make[2]: Entering directory >`/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' >/tmp/ccIEbMf3.s: Assembler messages: >/tmp/ccIEbMf3.s:8: Warning: Ignoring changed section attributes for >..modinfo >make[2]: Leaving directory >`/tmp/vmware-config3/vmmon-only/driver-2.4.0-SGI_XFS_PR' >make[1]: Leaving directory `/tmp/vmware-config3/vmmon-only' >make: Leaving directory `/tmp/vmware-config3/vmmon-only' >Unable to make a vmmon module that can be loaded in the running kernel: >/tmp/vmware-config3/vmmon.o: unresolved symbol irq_stat >There is probably a light difference of kernel configuration between the >set of C header files you specified and your running kernel. You may want >to rebuild a kernel based on that directory, or specify another directory. > >For more information on how to troubleshoot module-related problems, >please havea look at >"http://www.vmware.com/download/modules/modules.html". > >Execution aborted. > >*snip* > >this works fine under 2.4.0 kernel. (at least this is what vmware claims >:) > >-tduffy ---------------------------- John M Trostel jtrostel@mindspring.com email from my visor... cool!