From owner-linux-xfs@oss.sgi.com Tue Oct 1 02:24:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 02:24:32 -0700 (PDT) Received: from web15204.mail.bjs.yahoo.com ([61.135.128.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g919ONtG020044 for ; Tue, 1 Oct 2002 02:24:25 -0700 Message-ID: <20021001092416.74643.qmail@web15204.mail.bjs.yahoo.com> Received: from [202.237.246.10] by web15204.mail.bjs.yahoo.com via HTTP; Tue, 01 Oct 2002 17:24:16 CST Date: Tue, 1 Oct 2002 17:24:16 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: the shell will make the xfs fs locked To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs xfs-developers: when I run the shell program as following on a xfs FS, the process will locked. #!/bin/sh for((i=0;i<300000;i++)); do truncate /mnt/current/a $(($i*8192)); cat /tmp/4kfile >> /mnt/current/a done /tmp/4kfile is a 4096-sized file xfs FS mounted at /mnt/current the truncate program: #include #include #include int main(int argc, char *argv[]) { long long length = 0; if( argc < 2 || argc > 3 ){ printf("Usage: truncate filename [length]\n"); return -1; } if( argv[2] ) length = atoll(argv[2]); if( truncate64( argv[1], length ) ){ perror("truncate failed"); return -1; } return 0; } _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html From owner-linux-xfs@oss.sgi.com Tue Oct 1 02:25:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 02:25:23 -0700 (PDT) Received: from web15214.mail.bjs.yahoo.com ([61.135.128.144]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g919PHtG020172 for ; Tue, 1 Oct 2002 02:25:19 -0700 Message-ID: <20021001092510.58330.qmail@web15214.mail.bjs.yahoo.com> Received: from [210.72.245.13] by web15214.mail.bjs.yahoo.com via HTTP; Tue, 01 Oct 2002 17:25:10 CST Date: Tue, 1 Oct 2002 17:25:10 +0800 (CST) From: =?gb2312?q?jia=20mei?= Subject: 2.4.19 xfs oops report To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pagelaunder@yahoo.com.cn Precedence: bulk X-list: linux-xfs Hi xfs-gurus, XFS always oops in my stress testing, which is very simple: I just upload a large number of small files from 4 clients connecting server with gigabit switch. oops happens within around 6 hours or so. Sep 28 16:30:56 c100 kernel: Unable to handle kernel NULL pointer dereference at virtual address 000 0001b Sep 28 16:30:56 c100 kernel: printing eip: Sep 28 16:30:56 c100 kernel: c012e1d7 Sep 28 16:30:56 c100 kernel: *pde = 00000000 Sep 28 16:30:56 c100 kernel: Oops: 0000 Sep 28 16:30:56 c100 kernel: CPU: 0 Sep 28 16:30:56 c100 kernel: EIP: 0010:[unlock_page+7/112] Tainted: P Sep 28 16:30:56 c100 kernel: EIP: 0010:[] Tainted: P Sep 28 16:30:56 c100 kernel: EFLAGS: 00010297 Sep 28 16:30:56 c100 kernel: eax: 00000000 ebx: 00000000 ecx: c03214a0 edx: 00000000 Sep 28 16:30:56 c100 kernel: esi: 00000000 edi: c9ce23e0 ebp: f5f35798 esp: f5f35790 Sep 28 16:30:56 c100 kernel: ds: 0018 es: 0018 ss: 0018 Sep 28 16:30:56 c100 kernel: Process nfsd (pid: 1073, stackpage=f5f35000) Sep 28 16:30:56 c100 kernel: Stack: 000c003c 00000000 f5f357d8 f9a41d10 c9ce23e0 c9ce23e0 20024211 0 0000000 Sep 28 16:30:56 c100 kernel: 000c003c 00000000 00001000 00000001 00000000 fffffff4 ffffffff 0 0000000 Sep 28 16:30:56 c100 kernel: 000c003d 00000001 f5f357f8 f9a4217e c9ce23e0 f5fd6ab4 20024211 0 06001e0 the "Tainted: P" is because we must use the e1000 driver from Intel. kdb trace is: unlock_page _pagebuf_lookup_pages pagebuf_get pagebuf_readahead xfs_dir2_leaf_getdents xfs_dir2_getdents linvfs_readdir vfs_readdir nfsd_get_name splice nfsd_get_dentry inet_sendmsg svc_process nfsd kernel_thread we use 2002-09-16 snapshot of CVS code. kernel 2.4.19. #gcc -v Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) did anyone experienced the same oops? Now I can reproduce it. If need anymore information, I'd like to provide. thanks. -- Joe _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html From owner-linux-xfs@oss.sgi.com Tue Oct 1 05:33:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 05:33:43 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91CXatG011078 for ; Tue, 1 Oct 2002 05:33:37 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 FAA07787 for ; Tue, 1 Oct 2002 05:33:35 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g91CWODp004032 for ; Tue, 1 Oct 2002 14:32:24 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g91CWOBU004031 for linux-xfs@oss.sgi.com; Tue, 1 Oct 2002 14:32:24 +0200 Date: Tue, 1 Oct 2002 14:32:24 +0200 Message-Id: <200210011232.g91CWOBU004031@lab343.munich.sgi.com> Subject: TAKE - Back out intermezzo compile 'fix' To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs It doesn't compile with or without XFS in 2.5, we'll leave it to the maintainer to fix instead of increasing the delta of the XFS tree. Date: Tue Oct 1 05:32:07 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128783a linux/fs/intermezzo/journal_xfs.c - 1.7 - Don't #if 0 this file anymore. From owner-linux-xfs@oss.sgi.com Tue Oct 1 07:52:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 07:52:36 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91EqVtG014336 for ; Tue, 1 Oct 2002 07:52:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA37144; Tue, 1 Oct 2002 09:52:25 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA34842; Tue, 1 Oct 2002 09:52:23 -0500 (CDT) Subject: Re: Convert Log Format from old to v2 format From: Eric Sandeen To: Oliver Jehle Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033447554.997.11.camel@vorab> References: <1029319626.1094.22.camel@vorab> <1029360439.21217.179.camel@stout.americas.sgi.com> <1033447554.997.11.camel@vorab> Content-Type: multipart/mixed; boundary="=-nDiRcNco5i13vqzC3Wxt" X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Oct 2002 09:51:19 -0500 Message-Id: <1033483880.16812.39.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs --=-nDiRcNco5i13vqzC3Wxt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oliver - Sorry for the delay, I guess this got lost in the shuffle. You will need a recent xfsprogs version for this to work, there was a bug in xfs_db that broke the script. Also, this script has not been heavily tested, and there are still some known problems with v2 logs, so please back up any important data first... There is a man page for the script, but it's out of date, so here are the relevant bits: [root@lite root]# ./xfs_chver=20 usage: xfs_chver [-f] -a xfs_chver [-f] [ -l version ] devname [devname ...] The -f option causes the xfs_chver command to reduce error checking and create file(s) which can be passed to xfs_db. These files are created = in the current directory in the form .xfs_chver. These files can= be applied to the filesystem, invoke the following command: xfs_db -x < .xfs_chver The -l option selects the log version, 1 or 2. -a may be used instead of devname, to change all xfs devices found in /etc/fstab -Eric On Mon, 2002-09-30 at 23:45, Oliver Jehle wrote: > Hi Eric.... >=20 > i like to convert my current system (evms1.0.0/xfs1.1.0) to evms(1.2.0) > and need to convert my log format to version 2. >=20 > can you give me a hint where i can find the script to change the log > format ???? >=20 > thanks >=20 > oliver >=20 >=20 > On Wed, 2002-08-14 at 23:27, Eric Sandeen wrote: > > Hi Oliver - > >=20 > > There is a script here that's a perl wrapper around xfs_db - let me look > > at it a bit and see what shape it's in. If it looks sane I'll put it > > out there for testing. > >=20 > > Thanks, > >=20 > > -Eric > >=20 > >=20 > > On Wed, 2002-08-14 at 05:07, Oliver Jehle wrote: > > > is there a way to convert the logging format from old xfs-filestem to > > > the new version 2 logging in xfs without backup/recreate/restore the > > > filesystem ??? for example unmounting, run utility, mount it...=20 > >=20 > > --=20 > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. 651-683-3102 > >=20 > --=20 > Oliver Jehle=09=09=09 > Monex AG > F=F6hrenweg 18 > FL-9496 Balzers >=20 > Tel: +423 388 1988 > Fax: +423 388 1980 >=20 > ---- > I've not lost my mind. It's backed up on tape somewhere. > ---- --=20 Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --=-nDiRcNco5i13vqzC3Wxt Content-Disposition: attachment; filename=xfs_chver Content-Transfer-Encoding: quoted-printable Content-Type: text/x-perl; name=xfs_chver; charset=ISO-8859-1 #!/usr/bin/perl #ident "$Id: xfs_chver,v 1.1 1998/06/08 19:39:11 mostek Exp $" # # This program works with a device (an XFS file system) and updates # it's version to set the "extent unwritten version" flag and # log version. # # Unwritten extents are not supported on Linux, so are not allowed # in this script. # use strict; my($prog, $dev, $version, $progjunk, $equ, $junk, $nver, $agcount, $tmp_fil= e, $mod_string, $ag, $count, $all, $rest, $devnum, $d, $usage, $mdev, $rootdevno, $mydevno, $ino, $mode, $nlink, $uid, $gid, $save_script, $base, @args, %mlist, @devlist, $device, $directory, $type, $unwritten, $setlogversion, $logversion); use File::Basename; $save_script =3D 0; $prog =3D "xfs_chver"; $usage =3D "usage: $prog [-f] [ -l version ] -a\n\t$prog [-f] [ -l version= ] devname [devname ...]\n"; $all =3D 0; $setlogversion =3D 0; $unwritten =3D 0; while($_ =3D $ARGV[0], /^-/) { shift; if (/^-a$/) { $all =3D 1; } elsif (/^-f/) { $save_script =3D 1; } elsif (/^-u/) { print "Unwritten extents unsupported on Linux.\n"; printf($usage); exit 1; } elsif (/^-l/) { $setlogversion =3D 1; $logversion =3D $ARGV[0]; shift; if ($logversion !=3D "1" && $logversion !=3D "2") { print "Invalid log version $logversion. Version must be 1 or 2\n"; printf($usage); exit 1; } } else { printf($usage); exit 1; } } if ($all && $ARGV[0]) { printf($usage); exit 1; } elsif ($ARGV[0] eq "" && !$all) { printf($usage); exit 1; } # Default action is to update the 'unwritten' flag #if ($setlogversion =3D=3D 0 && $unwritten =3D=3D 0) { # $unwritten =3D 1; #} # Unwritten extents unsupported on Linux, logv2 is experimental # -No- default action. if ($setlogversion =3D=3D 0 && $unwritten =3D=3D 0) { print "No log version specified.\n"; printf($usage); exit 1; } # # if all, build an array of devices that are not mounted and # are in /etc/fstab. # otherwise, use the list from ARGV. # if ($all) { open FSTAB, "/etc/fstab" or die("$prog: can't open /etc/fstab\n"); $devnum =3D 0; while () { if (!/^#/) { ($device, $directory, $type, $rest) =3D split(/\s+/); if ($type eq "xfs") { $devlist[$devnum] =3D $device; $devnum =3D $devnum+1; } } } } else { @devlist =3D @ARGV; } ($d, $ino, $mode, $nlink, $uid, $gid, $rootdevno, $rest) =3D stat "/dev/roo= t"; open MTAB, "/etc/mtab" or die("$prog: can't open /etc/mtab\n"); while () { ($device, $directory, $type, $rest) =3D split(/\s+/); if ($type eq "xfs") { $mlist{$device} =3D 1; } } close(MTAB); for($devnum =3D 0; $devlist[$devnum]; $devnum =3D $devnum+1) { $dev =3D $devlist[$devnum]; ($d, $ino, $mode, $nlink, $uid, $gid, $mydevno, $rest) =3D stat $dev; if (!$save_script && ($mydevno =3D=3D $rootdevno)) { printf("$prog: $dev is root so can't change version.\n"); printf("$prog: must unmount $dev and change using another root or miniroo= t.\n"); next; } if (!$save_script && $mlist{$dev}) { printf("$prog: $dev mounted so can't change version.\n"); printf("$prog: unmount $dev and try again. Skipping $dev.\n"); next; } if (!-e $dev) { printf("$prog: $dev does not exist.\n"); next; } if (!(-r $dev) && ($save_script)) { printf("$prog: can't read $dev. Are you root?\n"); next; } if (!$save_script && (!(-r $dev) || !(-w $dev))) { printf("$prog: can't read or write $dev to update. Are you root?\n"); next; } open CUR_VERSION, "xfs_db -c 'sb 0' -c 'p versionnum' -r $dev |" or die("can't exec xfs_db -c 'sb 0' -c 'p versionnum' -r $dev to get version= "); $version =3D 0; while() { if (/versionnum/) { chop; ($junk, $equ, $version) =3D split(/ /); $version =3D oct $version; } else { print("$prog: didn't get versionnum in $dev."); print("got: ($_) instead.\n"); print("$prog: skipping $dev.\n"); next; } } if ($version =3D=3D 0) { print("$prog: nothing came back from xfs_db for $dev, skipping!\n"); next; } close CUR_VERSION; if ($version =3D=3D 1) { $nver =3D 0x0004; $nver |=3D 0x1000 if ($unwritten); $nver |=3D 0x0400 if ($setlogversion && $logversion =3D=3D 2); } elsif ($version =3D=3D 2) { $nver =3D 0x0014; $nver |=3D 0x1000 if ($unwritten); $nver |=3D 0x0400 if ($setlogversion && $logversion =3D=3D 2); } elsif ($version =3D=3D 3) { $nver =3D 0x0034; $nver |=3D 0x1000 if ($unwritten); $nver |=3D 0x0400 if ($setlogversion && $logversion =3D=3D 2); } elsif ($version & 0x1000 && $unwritten) { printf("$prog: $dev has new format 0x%x. Nothing to do.\n", $version); next; } else { $nver =3D $version; $nver |=3D 0x1000 if ($unwritten); $nver |=3D 0x0400 if ($setlogversion && $logversion =3D=3D 2); $nver &=3D ~0x400 if ($setlogversion && $logversion =3D=3D 1); } open AG, "xfs_db -c 'sb 0' -c 'p agcount' -r $dev |" or die("can't exec xfs_db -c 'sb 0' -c 'p agcount' -r $dev to get agcount\n= "); $agcount =3D -1; while() { if (/agcount/) { chop; ($junk, $equ, $agcount) =3D split(/ /); } else { print("$prog: didn't get agcount in $dev, got: $_ instead\n"); print("$prog: skipping $dev\n"); next; } } if ($agcount =3D=3D -1) { print("nothing came back from xfs_db for agcount, quitting!\n"); print("$prog: NO agcount in $dev, skipping.\n"); next; } close AG; if (!$save_script) { printf("$prog: $dev: changing version 0x%x to 0x%x in $agcount AGs\n", $version, $nver, $agcount); } # # Tried to do the following by writing directly to xfs_db. It wouldn't work # for some reason eventhough cat, and other programs would see # all the commands. For some reason, we need to put the commands # in a temp file and read it back in. # Would like to do the following but it doesn't work. #open(MODIFY, "| xfs_db -x $dev ") or die("can't exec xfs_db -x $dev to fi= x versions\n"); # $tmp_file =3D "/tmp/xfs_db.in$$"; open(TMPFILE, ">$tmp_file") or die("can't create $tmp_file"); $mod_string =3D ""; for ($ag =3D 0; $ag < $agcount; $ag =3D $ag + 1) { $mod_string .=3D sprintf("sb $ag\nwrite versionnum 0x%x\n", $nver); } print(TMPFILE "$mod_string"); close TMPFILE; if ($save_script) { $base =3D basename($dev); $base .=3D ".xfs_chver"; @args =3D ("mv", "$tmp_file", "$base"); system(@args) =3D=3D 0 or die("$prog: can't save $tmp_file in $base\n"); printf("$prog: run \"xfs_db -x $dev < $base\"\n"); } else { open(MODIFY, "xfs_db -x $dev < $tmp_file |") or die("can't exec xfs_db -x $dev < $tmp_file to fix versions\n"); while() { if (/versionnum =3D /) { $count =3D $count + 1; } elsif (!/xfs_db:/) { printf("$prog: got $_ back from xfs_db, continue.\n"); } } if ($count !=3D $agcount) { printf("$prog: WARNING: $count updated instead of $agcount?\n"); printf("$prog: see $tmp_file for input to xfs_db -x $dev.\n"); next; } else { @args =3D ("rm", "$tmp_file"); system(@args) =3D=3D 0 or die("$prog: can't remove $tmp_file\n"); } close MODIFY; $count =3D 0; } } exit 0; --=-nDiRcNco5i13vqzC3Wxt-- From owner-linux-xfs@oss.sgi.com Tue Oct 1 08:01:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 08:01:36 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91F1UtG015261 for ; Tue, 1 Oct 2002 08:01:30 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 IAA07951 for ; Tue, 1 Oct 2002 08:01:29 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g91F0jVu000956 for ; Tue, 1 Oct 2002 17:00:45 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g91F0jKo000955 for linux-xfs@oss.sgi.com; Tue, 1 Oct 2002 17:00:45 +0200 Date: Tue, 1 Oct 2002 17:00:45 +0200 Message-Id: <200210011500.g91F0jKo000955@lab343.munich.sgi.com> Subject: TAKE - Handle NULL pagebufs gracefully in pagebuf_geterror To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Oct 1 08:00:51 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:128787a linux/fs/xfs/pagebuf/page_buf.h - 1.42 - Return ENOMEM for NULL pagebufs in pagebuf_geterror. From owner-linux-xfs@oss.sgi.com Tue Oct 1 09:49:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 09:49:19 -0700 (PDT) Received: from motion.christooley.cjb.net (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91GnHtG025222 for ; Tue, 1 Oct 2002 09:49:17 -0700 Received: (from ctooley@localhost) by motion.christooley.cjb.net (8.11.6/8.11.6) id g91Gn3Y02885; Tue, 1 Oct 2002 11:49:03 -0500 X-Authentication-Warning: motion.christooley.cjb.net: ctooley set sender to ctooley@amoa.org using -f Subject: Distribution From: Chris Tooley To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Oct 2002 11:49:02 -0500 Message-Id: <1033490942.2543.9.camel@motion> Mime-Version: 1.0 X-archive-position: 683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs Now that XFS has got "official" support of the kernel gods, is there anyone leaning on RedHat to get it in their distribution. I don't really want the XFS team to have to have the additional task (note I didn't use responsibility) of making installer CD's for RedHat, anymore than they want to have to do it. Would it be stepping on anyone's toes if we started mailing RedHat to ask that this get included in 8.1? Chris From owner-linux-xfs@oss.sgi.com Tue Oct 1 10:02:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 10:02:52 -0700 (PDT) Received: from ns.caxopen.de (IDENT:root@caxopen-gw.caxopen.com [194.55.1.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91H2ntG026192 for ; Tue, 1 Oct 2002 10:02:49 -0700 Received: from caxopen.de (V4Ueyy8YQUbmEPaQBVM0sPNuKVdErloR@minos.intern.net [192.168.1.28]) by ns.caxopen.de (8.8.7/8.8.7) with ESMTP id TAA00776 for ; Tue, 1 Oct 2002 19:03:12 +0200 Message-ID: <3D99D537.3090005@caxopen.de> Date: Tue, 01 Oct 2002 19:02:47 +0200 From: Andreas Korn Reply-To: korn@caxopen.de Organization: CAxOPEN GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Distribution References: <1033490942.2543.9.camel@motion> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: korn@caxopen.de Precedence: bulk X-list: linux-xfs Would be nice if they would do it. I'm in for it. Andreas Chris Tooley wrote: > Now that XFS has got "official" support of the kernel gods, is there > anyone leaning on RedHat to get it in their distribution. I don't > really want the XFS team to have to have the additional task (note I > didn't use responsibility) of making installer CD's for RedHat, anymore > than they want to have to do it. Would it be stepping on anyone's toes > if we started mailing RedHat to ask that this get included in 8.1? > > Chris > > > -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger! From owner-linux-xfs@oss.sgi.com Tue Oct 1 11:34:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 11:34:30 -0700 (PDT) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91IYOtG028341 for ; Tue, 1 Oct 2002 11:34:24 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DC4FF2FA71 for ; Tue, 1 Oct 2002 11:34:23 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 1A3532FA71 for ; Tue, 1 Oct 2002 11:34:20 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id BF52F3438 for ; Tue, 1 Oct 2002 11:34:09 -0700 (PDT) Subject: Re: Distribution From: Florin Andrei To: linux-xfs In-Reply-To: <1033490942.2543.9.camel@motion> References: <1033490942.2543.9.camel@motion> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Oct 2002 11:34:09 -0700 Message-Id: <1033497249.17638.23.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-10-01 at 09:49, Chris Tooley wrote: > Now that XFS has got "official" support of the kernel gods, is there > anyone leaning on RedHat to get it in their distribution. I don't > really want the XFS team to have to have the additional task (note I > didn't use responsibility) of making installer CD's for RedHat, anymore > than they want to have to do it. Would it be stepping on anyone's toes > if we started mailing RedHat to ask that this get included in 8.1? The problem has been asked many times, and the answer is obvious: the more messages they'll get from their customers, the bigger the chances to include XFS in the distribution (in a non-hidden way, like ReiserFS was for a long time, and still is i think). So... use the force^H^H^H^H^He-mail. ;-) -- Florin Andrei "To a first approximation, bank vaults are secure. Most of them don't get broken into, because it takes real skill. Computers are the opposite." - Bruce Schneier From owner-linux-xfs@oss.sgi.com Tue Oct 1 13:50:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 13:50:32 -0700 (PDT) Received: from darwin.libc.org (ucntcme224.dsl.micron.net [206.207.111.224] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91KoPtG031543 for ; Tue, 1 Oct 2002 13:50:25 -0700 Received: (qmail 30370 invoked from network); 1 Oct 2002 20:49:31 -0000 Received: from unknown (HELO ?192.168.1.12?) (?4ZEjnu4DNTbaFjNZmK8PK/e/0tS18LeI?@192.168.1.12) by 192.168.1.11 with SMTP; 1 Oct 2002 20:49:31 -0000 Subject: Begging :^) From: Bill Anderson To: "Linux XFS (SGI)" In-Reply-To: <1033072740.29206.58.camel@stantz.corp.sgi.com> References: <20020920214701.58788.qmail@web40603.mail.yahoo.com> <1033072740.29206.58.camel@stantz.corp.sgi.com> Content-Type: text/plain Organization: Immosys Message-Id: <1033505411.1256.143.camel@locutus.libc.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1 (Preview Release) Date: 01 Oct 2002 14:50:11 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@immosys.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > > > Are there any pitfalls in incorporating Ingo Molnars > > O(1) scheduler to xfs-linux-2.4.18-r1.1 ? > > The patches in the current xfs CVS does not seem to > > be applicable. > > Any insights or experiences ? > > I guess a resolution to this problem (either negative or positive) will > be enforced as soon as people will start begging for a "XFS-enabled Red > Hat 8.0 installer". ;-) The begging has now commenced. :) -- Bill Anderson Immosys Rebuilding the network of Tomorrow From owner-linux-xfs@oss.sgi.com Tue Oct 1 14:23:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 14:23:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91LNbtG000540 for ; Tue, 1 Oct 2002 14:23:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA70081 for ; Tue, 1 Oct 2002 16:23:32 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA48753 for ; Tue, 1 Oct 2002 16:23:32 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g91LMPB22283; Tue, 1 Oct 2002 16:22:25 -0500 Message-Id: <200210012122.g91LMPB22283@stout.americas.sgi.com> Date: Tue, 1 Oct 2002 16:22:25 -0500 Subject: TAKE - KDB: Add dirty data buffers to output of inode command X-archive-position: 687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs kdb> inode showed dirty buffers, but not dirty data buffers. go figure :) KDB: Add dirty data buffers to output of inode command Date: Tue Oct 1 14:22:56 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128823a linux/kdb/modules/kdbm_pg.c - 1.58 - KDB: Add dirty data buffers to output of inode command From owner-linux-xfs@oss.sgi.com Tue Oct 1 15:15:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 15:15:58 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91MFrtG001628 for ; Tue, 1 Oct 2002 15:15:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA66109 for ; Tue, 1 Oct 2002 17:15:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA06418 for ; Tue, 1 Oct 2002 17:15:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g91MFbK17248; Tue, 1 Oct 2002 17:15:37 -0500 Message-Id: <200210012215.g91MFbK17248@jen.americas.sgi.com> Date: Tue, 1 Oct 2002 17:15:37 -0500 Subject: TAKE - merge up to 2.5.39 To: linux-xfs@oss.sgi.com X-archive-position: 688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Merge up with Linus again. Some of the extra changes we had due to kdb go away with the new ksyms code - does Linus know he is merging part of a debugger ;-) Steve Date: Tue Oct 1 15:12:20 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128837a linux/include/linux/netfilter_bridge/ebt_vlan.h - 1.1 linux/drivers/char/drm/radeon_mem.c - 1.1 linux/drivers/char/drm/radeon_irq.c - 1.1 linux/drivers/pci/pci.h - 1.1 linux/drivers/char/agp/k8-agp.c - 1.1 linux/drivers/block/deadline-iosched.c - 1.1 linux/drivers/base/hotplug.c - 1.1 linux/drivers/base/cpu.c - 1.1 linux/include/linux/cpu.h - 1.1 linux/include/linux/netfilter_bridge/ebt_arp.h - 1.1 linux/include/linux/netfilter_bridge/ebt_ip.h - 1.1 linux/include/linux/netfilter_bridge/ebt_log.h - 1.1 linux/include/linux/netfilter_bridge/ebt_redirect.h - 1.1 linux/include/linux/netfilter_bridge/ebtables.h - 1.1 linux/include/linux/vcache.h - 1.1 linux/mm/vcache.c - 1.1 linux/include/linux/netfilter_bridge/ebt_nat.h - 1.1 linux/include/linux/netfilter_bridge/ebt_mark_m.h - 1.1 linux/include/linux/netfilter_bridge/ebt_mark_t.h - 1.1 linux/net/x25/x25_route.c - 1.8 linux/net/x25/x25_in.c - 1.11 linux/net/x25/sysctl_net_x25.c - 1.4 linux/net/x25/af_x25.c - 1.29 linux/net/irda/wrapper.c - 1.12 linux/net/irda/qos.c - 1.16 linux/net/irda/irttp.c - 1.20 linux/net/irda/irqueue.c - 1.11 linux/net/irda/irlmp_frame.c - 1.13 linux/net/irda/irlmp_event.c - 1.19 linux/net/irda/irlmp.c - 1.22 linux/net/irda/irlap_frame.c - 1.17 linux/net/irda/irlap_event.c - 1.25 linux/net/irda/irlap.c - 1.21 linux/net/irda/irlan/irlan_provider_event.c - 1.4 linux/net/irda/irlan/irlan_provider.c - 1.7 linux/net/irda/irlan/irlan_filter.c - 1.4 linux/net/irda/irlan/irlan_event.c - 1.4 linux/net/irda/irlan/irlan_eth.c - 1.16 linux/net/irda/irlan/irlan_common.c - 1.21 linux/net/irda/irlan/irlan_client_event.c - 1.8 linux/net/irda/irlan/irlan_client.c - 1.13 linux/net/irda/irias_object.c - 1.15 linux/net/irda/iriap_event.c - 1.10 linux/net/irda/iriap.c - 1.18 linux/net/irda/irda_device.c - 1.29 linux/net/irda/discovery.c - 1.9 linux/net/irda/af_irda.c - 1.41 linux/net/ipx/af_ipx.c - 1.30 linux/net/ipv6/udp.c - 1.30 linux/net/ipv6/ndisc.c - 1.24 linux/net/802/psnap.c - 1.10 linux/net/802/p8022.c - 1.11 linux/mm/vmscan.c - 1.114 linux/mm/swapfile.c - 1.65 linux/mm/slab.c - 1.41 linux/mm/page_alloc.c - 1.93 linux/mm/mprotect.c - 1.34 linux/mm/memory.c - 1.93 linux/mm/filemap.c - 1.136 linux/mm/Makefile - 1.18 linux/kernel/signal.c - 1.42 linux/kernel/sched.c - 1.83 linux/kernel/module.c - 1.29 linux/kernel/ksyms.c - 1.167 linux/kernel/fork.c - 1.71 linux/kernel/exit.c - 1.56 linux/kernel/Makefile - 1.35 linux/include/net/x25.h - 1.11 linux/include/net/p8022.h - 1.6 linux/include/net/ndisc.h - 1.8 linux/include/net/llc_state.h - 1.3 linux/include/net/llc_name.h - 1.3 linux/include/net/llc_frame.h - 1.3 linux/include/linux/x25.h - 1.4 linux/include/linux/wait.h - 1.17 linux/include/linux/smp.h - 1.22 linux/include/linux/sched.h - 1.85 linux/include/linux/pagemap.h - 1.47 linux/include/linux/netdevice.h - 1.38 linux/include/linux/module.h - 1.35 linux/include/linux/mm.h - 1.102 linux/include/linux/list.h - 1.20 linux/include/linux/kernel.h - 1.37 linux/include/linux/isdnif.h - 1.15 linux/include/linux/isdn.h - 1.25 linux/include/linux/genhd.h - 1.25 linux/include/linux/elf.h - 1.15 linux/include/linux/dcache.h - 1.27 linux/include/linux/blkdev.h - 1.70 linux/include/linux/amifd.h - 1.3 linux/include/asm-i386/semaphore.h - 1.17 linux/include/asm-i386/ptrace.h - 1.9 linux/include/asm-i386/io.h - 1.29 linux/include/asm-i386/hardirq.h - 1.24 linux/include/asm-alpha/unistd.h - 1.22 linux/include/asm-alpha/spinlock.h - 1.15 linux/include/asm-alpha/ide.h - 1.12 linux/include/asm-alpha/hardirq.h - 1.15 linux/fs/locks.c - 1.33 linux/fs/inode.c - 1.82 linux/fs/ext2/ialloc.c - 1.29 linux/fs/exec.c - 1.67 linux/fs/dquot.c - 1.61 linux/fs/dcache.c - 1.41 linux/fs/buffer.c - 1.136 linux/fs/block_dev.c - 1.62 linux/drivers/scsi/sr.c - 1.52 linux/drivers/scsi/sd.c - 1.71 linux/drivers/net/irda/w83977af_ir.c - 1.26 linux/drivers/net/irda/tekram.c - 1.11 linux/drivers/char/tty_io.c - 1.53 linux/drivers/char/sysrq.c - 1.29 linux/drivers/cdrom/sonycd535.c - 1.28 linux/drivers/cdrom/mcd.c - 1.22 linux/drivers/cdrom/gscd.c - 1.22 linux/drivers/cdrom/cdu31a.c - 1.22 linux/drivers/block/z2ram.c - 1.18 linux/drivers/block/xd.c - 1.45 linux/drivers/block/rd.c - 1.60 linux/drivers/block/ps2esdi.c - 1.47 linux/drivers/block/paride/pd.c - 1.37 linux/drivers/block/loop.c - 1.67 linux/drivers/block/ll_rw_blk.c - 1.115 linux/drivers/block/genhd.c - 1.34 linux/drivers/block/floppy.c - 1.51 linux/drivers/block/ataflop.c - 1.27 linux/drivers/block/amiflop.c - 1.28 linux/drivers/block/Makefile - 1.29 linux/drivers/acorn/block/fd1772.c - 1.21 linux/arch/sparc64/mm/Makefile - 1.10 linux/arch/sparc64/math-emu/Makefile - 1.6 linux/arch/sparc64/kernel/sys_sparc32.c - 1.57 linux/arch/sparc64/kernel/ioctl32.c - 1.57 linux/arch/sparc64/kernel/Makefile - 1.25 linux/arch/sparc64/Makefile - 1.22 linux/arch/sparc/mm/Makefile - 1.11 linux/arch/sparc/math-emu/Makefile - 1.10 linux/arch/sparc/kernel/Makefile - 1.18 linux/arch/sparc/Makefile - 1.16 linux/arch/ppc/mm/Makefile - 1.12 linux/arch/ppc/lib/Makefile - 1.11 linux/arch/ppc/kernel/Makefile - 1.32 linux/arch/ppc/amiga/Makefile - 1.10 linux/arch/ppc/Makefile - 1.29 linux/arch/ppc/8xx_io/Makefile - 1.10 linux/arch/mips/sni/Makefile - 1.9 linux/arch/mips/sgi/kernel/Makefile - 1.11 linux/arch/mips/mm/Makefile - 1.8 linux/arch/mips/kernel/Makefile - 1.12 linux/arch/mips/jazz/Makefile - 1.8 linux/arch/mips/Makefile - 1.15 linux/arch/m68k/sun3x/Makefile - 1.6 linux/arch/m68k/q40/Makefile - 1.4 linux/arch/m68k/mvme16x/Makefile - 1.5 linux/arch/m68k/mvme147/Makefile - 1.4 linux/arch/m68k/mm/Makefile - 1.5 linux/arch/m68k/mac/Makefile - 1.6 linux/arch/m68k/kernel/Makefile - 1.11 linux/arch/m68k/ifpsp060/Makefile - 1.7 linux/arch/m68k/hp300/Makefile - 1.5 linux/arch/m68k/fpsp040/Makefile - 1.7 linux/arch/m68k/bvme6000/Makefile - 1.4 linux/arch/m68k/atari/Makefile - 1.6 linux/arch/m68k/apollo/Makefile - 1.5 linux/arch/m68k/amiga/Makefile - 1.4 linux/arch/m68k/Makefile - 1.11 linux/arch/i386/kernel/traps.c - 1.61 linux/arch/i386/kernel/time.c - 1.27 linux/arch/i386/kernel/sys_i386.c - 1.10 linux/arch/i386/kernel/process.c - 1.57 linux/arch/i386/kernel/i386_ksyms.c - 1.56 linux/arch/i386/kernel/head.S - 1.27 linux/arch/i386/defconfig - 1.113 linux/arch/i386/config.in - 1.92 linux/arch/i386/boot/compressed/misc.c - 1.16 linux/arch/arm/mm/Makefile - 1.20 linux/arch/arm/kernel/Makefile - 1.22 linux/arch/arm/Makefile - 1.34 linux/arch/alpha/mm/Makefile - 1.4 linux/arch/alpha/math-emu/Makefile - 1.8 linux/arch/alpha/lib/Makefile - 1.17 linux/arch/alpha/kernel/time.c - 1.24 linux/arch/alpha/kernel/entry.S - 1.30 linux/arch/alpha/kernel/Makefile - 1.24 linux/arch/alpha/Makefile - 1.21 linux/Makefile - 1.220 linux/MAINTAINERS - 1.118 linux/drivers/net/irda/toshoboe.c - 1.31 linux/drivers/net/irda/smc-ircc.c - 1.27 linux/arch/ppc/xmon/Makefile - 1.7 linux/arch/i386/vmlinux.lds.S - 1.7 linux/arch/arm/nwfpe/Makefile - 1.8 linux/arch/mips/dec/boot/Makefile - 1.5 linux/arch/mips/dec/Makefile - 1.7 linux/arch/mips/baget/Makefile - 1.7 linux/fs/partitions/check.c - 1.53 linux/drivers/pnp/isapnp.c - 1.28 linux/arch/m68k/math-emu/Makefile - 1.7 linux/arch/i386/kernel/i8259.c - 1.34 linux/drivers/net/sis900.c - 1.35 linux/drivers/net/sb1000.c - 1.18 linux/arch/ppc/math-emu/Makefile - 1.5 linux/drivers/block/DAC960.c - 1.56 linux/arch/sh/mm/Makefile - 1.7 linux/arch/sh/kernel/Makefile - 1.16 linux/arch/sh/Makefile - 1.14 linux/net/irda/parameters.c - 1.11 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.10 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.12 linux/net/irda/ircomm/ircomm_tty.c - 1.23 linux/net/irda/ircomm/ircomm_ttp.c - 1.7 linux/net/irda/ircomm/ircomm_param.c - 1.11 linux/net/irda/ircomm/ircomm_lmp.c - 1.9 linux/net/irda/ircomm/ircomm_event.c - 1.6 linux/net/irda/ircomm/ircomm_core.c - 1.18 linux/arch/m68k/sun3/prom/Makefile - 1.3 linux/arch/m68k/sun3/Makefile - 1.8 linux/drivers/char/drm/drmP.h - 1.19 linux/drivers/char/drm/Makefile - 1.15 linux/include/linux/acpi.h - 1.30 linux/arch/i386/kernel/smpboot.c - 1.48 linux/include/linux/pci_ids.h - 1.74 linux/mm/highmem.c - 1.44 linux/include/linux/agp_backend.h - 1.20 linux/drivers/char/agp/Makefile - 1.9 linux/kernel/timer.c - 1.30 linux/drivers/char/agp/agp.h - 1.28 linux/drivers/i2c/i2c-dev.c - 1.21 linux/drivers/i2c/i2c-core.c - 1.17 linux/Documentation/usb/usb-serial.txt - 1.22 linux/arch/i386/kernel/mpparse.c - 1.26 linux/drivers/scsi/3w-xxxx.h - 1.13 linux/drivers/scsi/3w-xxxx.c - 1.21 linux/arch/ia64/ia32/Makefile - 1.10 linux/arch/ia64/hp/Makefile - 1.7 linux/arch/ia64/dig/Makefile - 1.7 linux/arch/ia64/Makefile - 1.21 linux/arch/mips/ddb5074/Makefile - 1.6 linux/drivers/video/matrox/matroxfb_base.h - 1.15 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.13 linux/arch/mips64/mm/Makefile - 1.5 linux/arch/mips64/sgi-ip27/Makefile - 1.9 linux/arch/mips64/Makefile - 1.15 linux/arch/mips64/kernel/Makefile - 1.7 linux/include/linux/brlock.h - 1.11 linux/drivers/usb/serial/whiteheat.h - 1.5 linux/drivers/usb/serial/usb-serial.h - 1.23 linux/drivers/ide/ide.c - 1.69 linux/drivers/block/elevator.c - 1.23 linux/include/linux/elevator.h - 1.13 linux/net/ipv4/netfilter/ipt_unclean.c - 1.8 linux/net/ipv4/netfilter/ipchains_core.c - 1.13 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.9 linux/drivers/usb/serial/whiteheat_fw.h - 1.4 linux/drivers/usb/serial/usbserial.c - 1.42 linux/drivers/usb/serial/whiteheat.c - 1.30 linux/arch/ppc/8260_io/Makefile - 1.6 linux/arch/s390/Makefile - 1.11 linux/arch/s390/kernel/Makefile - 1.8 linux/arch/s390/mm/Makefile - 1.4 linux/net/ipv6/netfilter/ip6_tables.c - 1.15 linux/kernel/kallsyms.c - 1.13 linux/include/linux/kallsyms.h - 1.10 linux/drivers/usb/storage/transport.h - 1.11 linux/drivers/usb/storage/transport.c - 1.28 linux/drivers/acpi/tables.c - 1.8 linux/drivers/mtd/ftl.c - 1.24 linux/drivers/mtd/mtdblock.c - 1.22 linux/drivers/usb/storage/shuttle_usbat.c - 1.12 linux/drivers/usb/storage/sddr09.c - 1.19 linux/drivers/usb/storage/freecom.c - 1.15 linux/drivers/input/mousedev.c - 1.14 linux/arch/arm/mach-footbridge/Makefile - 1.8 linux/arch/arm/mach-sa1100/Makefile - 1.13 linux/arch/arm/mach-shark/Makefile - 1.6 linux/drivers/md/md.c - 1.57 linux/net/irda/irsyms.c - 1.8 linux/net/irda/irnet/irnet_irda.h - 1.5 linux/net/irda/irnet/irnet.h - 1.12 linux/arch/parisc/mm/Makefile - 1.2 linux/arch/parisc/kernel/Makefile - 1.3 linux/arch/parisc/hpux/Makefile - 1.3 linux/arch/parisc/Makefile - 1.7 linux/arch/ia64/sn/io/Makefile - 1.6 linux/drivers/char/drm/radeon_cp.c - 1.10 linux/drivers/char/drm/radeon_drm.h - 1.6 linux/drivers/char/drm/radeon_drv.h - 1.8 linux/drivers/char/drm/radeon_state.c - 1.7 linux/fs/reiserfs/bitmap.c - 1.20 linux/drivers/usb/storage/unusual_devs.h - 1.13 linux/arch/cris/Makefile - 1.14 linux/arch/cris/drivers/Makefile - 1.5 linux/arch/cris/kernel/Makefile - 1.12 linux/arch/cris/mm/Makefile - 1.3 linux/drivers/s390/char/tapeblock.c - 1.13 linux/arch/s390x/kernel/Makefile - 1.8 linux/arch/s390x/mm/Makefile - 1.3 linux/drivers/s390/block/xpram.c - 1.25 linux/arch/s390x/boot/Makefile - 1.10 linux/arch/s390x/Makefile - 1.11 linux/arch/arm/mach-integrator/Makefile - 1.4 linux/arch/s390/math-emu/Makefile - 1.3 linux/arch/arm/mach-ebsa110/Makefile - 1.4 linux/arch/mips/mips-boards/malta/Makefile - 1.3 linux/arch/mips/mips-boards/generic/Makefile - 1.4 linux/arch/mips/mips-boards/atlas/Makefile - 1.4 linux/arch/mips/math-emu/Makefile - 1.3 linux/arch/mips/ite-boards/qed-4n-s01b/Makefile - 1.5 linux/arch/mips/ite-boards/generic/Makefile - 1.5 linux/arch/mips/ddb5476/Makefile - 1.4 linux/include/linux/rwsem.h - 1.5 linux/drivers/net/irda/irda-usb.c - 1.24 linux/drivers/net/wireless/airport.c - 1.8 linux/drivers/net/wireless/hermes.c - 1.8 linux/drivers/net/wireless/hermes.h - 1.9 linux/drivers/net/wireless/orinoco.c - 1.10 linux/drivers/net/wireless/orinoco.h - 1.8 linux/drivers/net/wireless/orinoco_cs.c - 1.10 linux/arch/ppc/boot/prep/Makefile - 1.11 linux/include/net/irda/irda-usb.h - 1.7 linux/drivers/acpi/Config.in - 1.10 linux/drivers/net/wireless/airo.c - 1.20 linux/arch/sh/stboards/Makefile - 1.3 linux/arch/mips64/math-emu/Makefile - 1.3 linux/drivers/net/irda/ali-ircc.c - 1.11 linux/arch/cris/drivers/lpslave/Makefile - 1.2 linux/drivers/usb/usb-skeleton.c - 1.15 linux/include/asm-alpha/rwsem.h - 1.4 linux/drivers/usb/storage/jumpshot.c - 1.8 linux/drivers/usb/storage/datafab.c - 1.8 linux/drivers/char/drm/radeon.h - 1.4 linux/drivers/char/drm/drm_lock.h - 1.2 linux/drivers/char/drm/drm_drv.h - 1.8 linux/drivers/char/drm/drm_bufs.h - 1.3 linux/arch/arm/mach-anakin/Makefile - 1.3 linux/arch/mips/au1000/common/Makefile - 1.5 linux/arch/mips/au1000/pb1000/Makefile - 1.4 linux/arch/mips/ite-boards/ivr/Makefile - 1.4 linux/arch/mips64/sgi-ip32/Makefile - 1.4 linux/arch/mips/ddb5xxx/common/Makefile - 1.3 linux/arch/mips/ddb5xxx/ddb5477/Makefile - 1.4 linux/arch/mips/gt64120/common/Makefile - 1.3 linux/arch/mips/gt64120/momenco_ocelot/Makefile - 1.4 linux/arch/mips/philips/nino/Makefile - 1.4 linux/arch/mips64/mips-boards/malta/Makefile - 1.4 linux/arch/mips64/mips-boards/atlas/Makefile - 1.4 linux/arch/mips64/mips-boards/generic/Makefile - 1.4 linux/drivers/net/wireless/orinoco_plx.c - 1.6 linux/drivers/i2c/i2c-proc.c - 1.7 linux/drivers/pcmcia/i82092.c - 1.6 linux/arch/arm/mach-epxa10db/Makefile - 1.3 linux/fs/ext3/inode.c - 1.22 linux/include/linux/bio.h - 1.15 linux/fs/bio.c - 1.19 linux/include/linux/device.h - 1.18 linux/mm/mempool.c - 1.11 linux/arch/arm/mach-tbox/Makefile - 1.3 linux/arch/arm/mach-adifcc/Makefile - 1.3 linux/arch/arm/mach-arc/Makefile - 1.3 linux/arch/arm/mach-clps711x/Makefile - 1.4 linux/arch/arm/mach-clps7500/Makefile - 1.3 linux/arch/arm/mach-ftvpci/Makefile - 1.3 linux/arch/arm/mach-iop310/Makefile - 1.3 linux/arch/arm/mach-l7200/Makefile - 1.3 linux/arch/arm/mach-rpc/Makefile - 1.3 linux/include/linux/init_task.h - 1.13 linux/drivers/net/wireless/wavelan_cs.c - 1.8 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.5 linux/arch/i386/Config.help - 1.13 linux/drivers/base/core.c - 1.15 linux/drivers/base/Makefile - 1.8 linux/drivers/pci/pci-driver.c - 1.11 linux/drivers/pnp/pnpbios_proc.c - 1.4 linux/arch/ppc/4xx_io/Makefile - 1.3 linux/arch/ppc/boot/simple/Makefile - 1.6 linux/arch/ppc/iSeries/Makefile - 1.3 linux/arch/ppc/platforms/Makefile - 1.5 linux/arch/ppc64/Makefile - 1.10 linux/arch/ppc64/kernel/Makefile - 1.9 linux/arch/ppc64/lib/Makefile - 1.5 linux/arch/ppc64/mm/Makefile - 1.3 linux/arch/ppc64/xmon/Makefile - 1.2 linux/fs/jfs/jfs_dmap.c - 1.10 linux/fs/jfs/jfs_dtree.c - 1.9 linux/fs/jfs/jfs_imap.c - 1.10 linux/fs/jfs/jfs_logmgr.c - 1.19 linux/include/linux/futex.h - 1.5 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.4 linux/arch/ia64/sn/kernel/sn1/Makefile - 1.4 linux/kernel/futex.c - 1.8 linux/arch/ia64/sn/kernel/Makefile - 1.4 linux/drivers/usb/core/usb.c - 1.16 linux/drivers/usb/host/ehci-dbg.c - 1.7 linux/arch/arm/mach-pxa/Makefile - 1.4 linux/drivers/usb/host/ehci-hcd.c - 1.9 linux/drivers/usb/host/ehci-hub.c - 1.5 linux/drivers/usb/host/ehci-q.c - 1.10 linux/drivers/usb/host/ehci-sched.c - 1.9 linux/drivers/usb/host/ehci.h - 1.5 linux/drivers/usb/host/ohci-hcd.c - 1.11 linux/drivers/usb/host/ohci-q.c - 1.12 linux/drivers/base/sys.c - 1.4 linux/drivers/base/base.h - 1.8 linux/drivers/usb/misc/Config.help - 1.5 linux/mm/pdflush.c - 1.7 linux/drivers/isdn/i4l/isdn_ppp.c - 1.7 linux/drivers/isdn/i4l/isdn_net.h - 1.5 linux/drivers/isdn/i4l/isdn_net.c - 1.5 linux/drivers/isdn/i4l/isdn_common.c - 1.6 linux/arch/ia64/hp/sim/Makefile - 1.2 linux/drivers/net/wireless/ieee802_11.h - 1.2 linux/drivers/pci/hotplug.c - 1.5 linux/fs/fs-writeback.c - 1.8 linux/include/linux/page-flags.h - 1.11 linux/mm/page-writeback.c - 1.12 linux/include/linux/buffer_head.h - 1.11 linux/include/linux/backing-dev.h - 1.3 linux/drivers/usb/storage/sddr55.c - 1.3 linux/include/linux/writeback.h - 1.9 linux/drivers/char/drm/i830.h - 1.3 linux/kernel/suspend.c - 1.13 linux/drivers/char/drm/i830_drv.h - 1.2 linux/drivers/char/drm/i830_drv.c - 1.4 linux/drivers/char/drm/i830_dma.c - 1.4 linux/fs/mpage.c - 1.9 linux/drivers/usb/storage/raw_bulk.c - 1.4 linux/drivers/s390/block/dasd_genhd.c - 1.7 linux/arch/i386/kernel/cpu/common.c - 1.7 linux/drivers/net/irda/act200l.c - 1.3 linux/net/llc/llc_if.c - 1.5 linux/include/net/llc_sap.h - 1.4 linux/include/net/llc_if.h - 1.3 linux/include/net/llc_s_ev.h - 1.4 linux/include/net/llc_main.h - 1.5 linux/net/llc/llc_sock.c - 1.5 linux/net/llc/llc_sap.c - 1.5 linux/net/llc/llc_s_ac.c - 1.4 linux/net/llc/llc_s_ev.c - 1.4 linux/net/llc/llc_evnt.c - 1.4 linux/net/llc/llc_mac.c - 1.5 linux/net/llc/llc_c_ac.c - 1.6 linux/net/llc/llc_c_ev.c - 1.6 linux/net/llc/llc_main.c - 1.6 linux/net/llc/llc_conn.c - 1.5 linux/include/net/llc_c_ac.h - 1.4 linux/include/net/llc_c_ev.h - 1.5 linux/include/net/llc_conn.h - 1.4 linux/include/net/llc_evnt.h - 1.4 linux/fs/direct-io.c - 1.7 linux/drivers/char/agp/Config.in - 1.2 linux/drivers/char/agp/agp.c - 1.3 linux/drivers/char/drm/drm_os_linux.h - 1.2 linux/net/sched/sch_htb.c - 1.3 linux/drivers/usb/misc/usblcd.c - 1.3 linux/net/sctp/ulpevent.c - 1.2 linux/net/sctp/protocol.c - 1.3 linux/include/net/sctp/sctp.h - 1.2 linux/net/sctp/adler32.c - 1.2 linux/net/sctp/associola.c - 1.3 linux/net/sctp/bind_addr.c - 1.3 linux/net/sctp/command.c - 1.2 linux/net/sctp/debug.c - 1.2 linux/net/sctp/endpointola.c - 1.3 linux/net/sctp/input.c - 1.2 linux/net/sctp/ipv6.c - 1.2 linux/net/sctp/output.c - 1.2 linux/net/sctp/outqueue.c - 1.3 linux/net/sctp/primitive.c - 1.2 linux/include/net/sctp/constants.h - 1.2 linux/include/net/sctp/sm.h - 1.2 linux/net/sctp/sm_make_chunk.c - 1.3 linux/net/sctp/sm_sideeffect.c - 1.3 linux/net/sctp/sm_statefuns.c - 1.3 linux/include/net/sctp/structs.h - 1.3 linux/net/sctp/sm_statetable.c - 1.2 linux/net/sctp/socket.c - 1.3 linux/net/sctp/transport.c - 1.2 linux/net/sctp/ulpqueue.c - 1.2 linux/arch/um/ptproxy/Makefile - 1.2 linux/drivers/ide/setup-pci.c - 1.4 linux/drivers/ide/pci/trm290.c - 1.3 linux/drivers/ide/pci/sl82c105.c - 1.3 linux/drivers/ide/pci/cy82c693.h - 1.3 linux/drivers/ide/pci/cy82c693.c - 1.4 linux/drivers/ide/legacy/pdc4030.c - 1.2 linux/drivers/ide/ide-lib.c - 1.4 linux/arch/um/Makefile - 1.2 linux/arch/um/drivers/Makefile - 1.2 linux/arch/um/kernel/Makefile - 1.2 linux/arch/um/os-Linux/Makefile - 1.2 linux/arch/um/os-Linux/drivers/Makefile - 1.2 linux/arch/um/sys-i386/Makefile - 1.2 linux/arch/um/sys-ia64/Makefile - 1.2 linux/arch/um/sys-ppc/Makefile - 1.2 linux/kernel/pid.c - 1.2 linux/arch/i386/mach-generic/Makefile - 1.2 linux/arch/i386/mach-visws/Makefile - 1.2 linux/drivers/base/platform.c - 1.2 linux/include/linux/pid.h - 1.2 linux/arch/ppc/boot/openfirmware/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 1 22:26:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Oct 2002 22:26:48 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g925QgtG006301 for ; Tue, 1 Oct 2002 22:26:43 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 91041AC30; Wed, 2 Oct 2002 07:23:18 +0200 (CEST) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 9D0CF190BF; Wed, 2 Oct 2002 07:23:17 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 9CC3330881D; Wed, 2 Oct 2002 07:26:39 +0200 (CEST) Message-ID: <3D9A838F.8260B8AD@ch.sauter-bc.com> Date: Wed, 02 Oct 2002 07:26:39 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Bill Anderson Cc: "Linux XFS (SGI)" Subject: Re: Begging :^) References: <20020920214701.58788.qmail@web40603.mail.yahoo.com> <1033072740.29206.58.camel@stantz.corp.sgi.com> <1033505411.1256.143.camel@locutus.libc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Bill Anderson schrieb: > > On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > > > > > Are there any pitfalls in incorporating Ingo Molnars > > > O(1) scheduler to xfs-linux-2.4.18-r1.1 ? > > > The patches in the current xfs CVS does not seem to > > > be applicable. > > > Any insights or experiences ? > > > > I guess a resolution to this problem (either negative or positive) will > > be enforced as soon as people will start begging for a "XFS-enabled Red > > Hat 8.0 installer". ;-) > > The begging has now commenced. :) BTW, I've created a bugreport on RedHat Bugzilla for their last public beta release. I asked them to include XFS in their kernel now that it is clear they _will_ include it in future. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74170 I'm looking forward to 8.1 :) Simon > > -- > Bill Anderson > Immosys > Rebuilding the network of Tomorrow From owner-linux-xfs@oss.sgi.com Wed Oct 2 02:58:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 02:58:23 -0700 (PDT) Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g929wJtG020990 for ; Wed, 2 Oct 2002 02:58:20 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g929wC5S010161; Wed, 2 Oct 2002 11:58:12 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g929wCq02307; Wed, 2 Oct 2002 11:58:12 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 2 Oct 2002 11:58:12 +0200 (CEST) From: Seth Mos To: Simon Matter cc: Bill Anderson , "Linux XFS (SGI)" Subject: Re: Begging :^) In-Reply-To: <3D9A838F.8260B8AD@ch.sauter-bc.com> Message-ID: <20021002115719.C1780-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Wed, 2 Oct 2002, Simon Matter wrote: > Bill Anderson schrieb: > > > > On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > > > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: The bug is CLOSED and DEFERRED. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74170 > > I'm looking forward to 8.1 :) I think they really don't want to :-) Cheers From owner-linux-xfs@oss.sgi.com Wed Oct 2 04:07:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 04:07:17 -0700 (PDT) Received: from intro.peace.co.nz (ftp.peace.co.nz [202.14.141.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92B7DtG022779 for ; Wed, 2 Oct 2002 04:07:14 -0700 Received: from peace.com ([10.0.1.93]) by intro.peace.co.nz (8.9.3/8.9.3) with SMTP id XAA04840 for ; Wed, 2 Oct 2002 23:07:07 +1200 Received: from 10.0.200.3 (SquirrelMail authenticated user jamesb) by apollo.peace.co.nz with HTTP; Wed, 2 Oct 2002 23:07:08 +1200 (NZST) Message-ID: <4781.10.0.200.3.1033556828.squirrel@apollo.peace.co.nz> Date: Wed, 2 Oct 2002 23:07:08 +1200 (NZST) Subject: AIO and XFS? From: "James Braid" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Reply-To: james.braid@peace.com X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james.braid@peace.com Precedence: bulk X-list: linux-xfs Hi all, I'm currently trying to get AIO and XFS (from Andrea's tree, 2.4.20pre8aa1) to work together. At the moment, AIO works fine on my ext3/2 filesystems, but it breaks on XFS. (This is from doing a make check in the libaio source directory (I'm using Andrea's version of libaio btw)). Is XFS and AIO a hopeless combination or is it actually possible to get them to work together? If so, does anyone have any pointers on where I would start to look for the right bits of code to hack together? Or even better, has anyone got AIO and XFS working already? Cheers, James From owner-linux-xfs@oss.sgi.com Wed Oct 2 05:27:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 05:27:17 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92CR3tG024812 for ; Wed, 2 Oct 2002 05:27:12 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17wiaZ-0000tS-00; Wed, 02 Oct 2002 13:26:51 +0100 Date: Wed, 2 Oct 2002 13:26:51 +0100 From: Christoph Hellwig To: James Braid Cc: linux-xfs@oss.sgi.com Subject: Re: AIO and XFS? Message-ID: <20021002132651.A2141@infradead.org> References: <4781.10.0.200.3.1033556828.squirrel@apollo.peace.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4781.10.0.200.3.1033556828.squirrel@apollo.peace.co.nz>; from james.braid@peace.com on Wed, Oct 02, 2002 at 11:07:08PM +1200 X-archive-position: 692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Oct 02, 2002 at 11:07:08PM +1200, James Braid wrote: > Hi all, > > I'm currently trying to get AIO and XFS (from Andrea's tree, > 2.4.20pre8aa1) to work together. At the moment, AIO works fine on my > ext3/2 filesystems, but it breaks on XFS. (This is from doing a make check > in the libaio source directory (I'm using Andrea's version of libaio > btw)). > Is XFS and AIO a hopeless combination or is it actually possible to get > them to work together? If so, does anyone have any pointers on where I > would start to look for the right bits of code to hack together? > Or even better, has anyone got AIO and XFS working already? Of course it's possible. But it's not trivial. I'd suggest you wait for aio getting fully implemented in 2.5, you can be sure we'll adds supporti for XFS there as soon as possible. From owner-linux-xfs@oss.sgi.com Wed Oct 2 06:42:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 06:42:18 -0700 (PDT) Received: from mail.scan-plus.de (mail.scan-plus.de [212.75.33.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92DgBtG000598 for ; Wed, 2 Oct 2002 06:42:11 -0700 Received: from localhost.localdomain [212.75.33.152] by mail.scan-plus.de with ESMTP (SMTPD32-6.06) id A7AA9FB007E; Wed, 02 Oct 2002 15:42:02 +0200 Subject: XFS mount fail From: Daniel Gruendler To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Dub0TVII5f5Cb8qGLyxh" X-Mailer: Ximian Evolution 1.0.5 Date: 02 Oct 2002 15:42:36 +0200 Message-Id: <1033566157.19572.7.camel@zealot> Mime-Version: 1.0 X-archive-position: 693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gruendler@scan-plus.de Precedence: bulk X-list: linux-xfs --=-Dub0TVII5f5Cb8qGLyxh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi there, I've a problem repairing a broken xfs partitition. According to the FAQ at oss.sgi.com I should ask the list for help since the problem is known as a rare one and hard to debug[1]. The xfs partitition (sda7 in my case) was mounted to /var. After a reboot the '/var' was not mounted, so I checked `dmesg` and saw a bunch of errors like [2]. I tried to run xfs_repair - with no results[3]. Any ideas how I could save the data on this partitition? It's quite important... Thanks in advance, Daniel [1]: http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail [2]: XFS: bad magic number XFS: SB validate failed [3]: # xfs_repair -v /dev/sda7=20 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...[...]... candidate secondary superblock... error reading superblock 29 -- seek to offset 31138512896 failed unable to verify superblock, continuing... ...[...]... candidate secondary superblock... error reading superblock 29 -- seek to offset 31138512896 failed unable to verify superblock, continuing... --=20 ----------------------------------------------------------------- | Daniel Gruendler | ScanPlus GmbH NOC |=20 | Koenigstrasse 78 | 89077 Ulm Germany | | Tel +49 731 920 13 0 | Fax +49 731 920 13 29 | | http://www.scan-plus.de | gruendler@scan-plus.de | | Amtsgericht Ulm HRB 3220 | Geschaeftsfuehrer:Juergen Hoermann | | PGP-FP: 2DED F25F 5A96 521A 271D B8D3 C30C 4D20 CA30 BA11 | ----------------------------------------------------------------- --=-Dub0TVII5f5Cb8qGLyxh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9mvfMwwxNIMowuhERAj4ZAJ0VcGmZZAdRfiUuly8rDVIM8Lyy7wCgnXlj PIev4OpWrPnI9ivJ37/SFjw= =L0c+ -----END PGP SIGNATURE----- --=-Dub0TVII5f5Cb8qGLyxh-- From owner-linux-xfs@oss.sgi.com Wed Oct 2 07:14:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 07:14:54 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92EEptG001846 for ; Wed, 2 Oct 2002 07:14:52 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id D6C64AC37; Wed, 2 Oct 2002 16:11:26 +0200 (CEST) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 3718F190A9; Wed, 2 Oct 2002 16:11:25 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 89C4630881D; Wed, 2 Oct 2002 16:14:48 +0200 (CEST) Message-ID: <3D9AFF58.88845F87@ch.sauter-bc.com> Date: Wed, 02 Oct 2002 16:14:48 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Axel Thimm Cc: Seth Mos , Bill Anderson , "Linux XFS (SGI)" Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> <20021002155655.A7079@bonzo.nirvana> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Axel Thimm schrieb: > > On Wed, Oct 02, 2002 at 11:58:12AM +0200, Seth Mos wrote: > > On Wed, 2 Oct 2002, Simon Matter wrote: > > > Bill Anderson schrieb: > > > > > > > > On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > > > > > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74170 > > The bug is CLOSED and DEFERRED. > > This is ugly. People will be banging SGI's doors for a RedHat installer again, > and I could very well understand, that they wouldn't want to go through that > again and drop supporting XFS installers/anaconda for RedHat. After all the > SGI-XFS people should concentrate on kernel matters, not on anaconda. > > > > I'm looking forward to 8.1 :) > > I think they really don't want to :-) > > So people using XFS and RedHat in production will have to stay with 7.3 unless > SGI guys sacrifice their time again (for my personal benefit, I admit that I > hope they will). :( The problem is that whenever RedHat creates an errata kernel, it has to be rebuilt with XFS support. I'm sure they _will_ finally include XFS, at least the way they did it with ReiserFS and JFS. While that's not quite perfect, it's okay for me. Simon > -- > Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Wed Oct 2 07:46:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 07:46:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92Ek9tG004033 for ; Wed, 2 Oct 2002 07:46:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA76627 for ; Wed, 2 Oct 2002 09:46:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA20206 for ; Wed, 2 Oct 2002 09:46:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92Ejh008056; Wed, 2 Oct 2002 09:45:43 -0500 Message-Id: <200210021445.g92Ejh008056@jen.americas.sgi.com> Date: Wed, 2 Oct 2002 09:45:43 -0500 Subject: TAKE - remove some bit shifting constants we do not use To: linux-xfs@oss.sgi.com X-archive-position: 695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Not really worth mentioning... Date: Wed Oct 2 07:45:16 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128887a linux/fs/xfs/xfs_fs.h - 1.3 - remove some bit shifting constants we do not use From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:01:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:01:58 -0700 (PDT) Received: from w206.web2010.com (w206.web2010.com [216.157.52.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92F1utG004722 for ; Wed, 2 Oct 2002 08:01:56 -0700 Received: from avalanche (catv-d5de8916.bp01catv.broadband.hu [213.222.137.22]) by w206.web2010.com (8.9.3/8.9.0) with ESMTP id LAA10067 for ; Wed, 2 Oct 2002 11:01:19 -0400 (EDT) Content-Type: text/plain; charset="us-ascii" From: Gabor Forgacs To: linux-xfs@oss.sgi.com Subject: direct io on linux Date: Wed, 2 Oct 2002 17:02:04 +0200 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200210021702.04252.gabor@colorfront.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g92F1vtG004723 X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Hi all What are the possibilities to use direct io on linux with any filesystem ? I use xfs/O_DIRECT under irix, i am just wondering is the direct io is a viable solution under linux too. Generally what is the fastest disk access method under linux with raid 0 ? I should read sequentialy 9-12 mb files. Thanx From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:06:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:06:40 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92F6PtG005241 for ; Wed, 2 Oct 2002 08:06:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA68965; Wed, 2 Oct 2002 10:06:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA65620; Wed, 2 Oct 2002 10:06:19 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92F5wT09607; Wed, 2 Oct 2002 10:05:58 -0500 Subject: Re: direct io on linux From: Steve Lord To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210021702.04252.gabor@colorfront.com> References: <200210021702.04252.gabor@colorfront.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Oct 2002 10:05:57 -0500 Message-Id: <1033571157.6943.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-10-02 at 10:02, Gabor Forgacs wrote: > Hi all > > What are the possibilities to use direct io on linux with any filesystem ? > > I use xfs/O_DIRECT under irix, i am just wondering is the direct io is a > viable solution under linux too. Generally what is the fastest disk access > method under linux with raid 0 ? I should read sequentialy 9-12 mb files. > > Thanx > If you are reading a lot of files and only reading them once, then O_DIRECT would be your best bet. You should do some timing tests though. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:25:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:25:04 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FOxtG007387 for ; Wed, 2 Oct 2002 08:25:00 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 IAA01414 for ; Wed, 2 Oct 2002 08:24:58 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id BAA50412 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 01:23:40 +1000 (EST) Date: Thu, 3 Oct 2002 01:23:40 +1000 (EST) From: Nathan Scott Message-Id: <200210021523.BAA50412@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACL docs X-archive-position: 698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Documentation cleanups relating to ACLs. Date: Wed Oct 2 08:17:36 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128889a linux/fs/Config.help - 1.19 - Documentation cleanups relating to ACLs. linux/fs/Config.in - 1.98 - Use the same ordering of config items in Config.in|help. linux/include/linux/posix_acl_xattr.h - 1.2 - We changed a bunch of stuff here, sync the copyright notice with that of fs/xattr.c. From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:25:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:26:00 -0700 (PDT) Received: from imf13bis.bellsouth.net (mail213.mail.bellsouth.net [205.152.58.153]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FPvtG007719 for ; Wed, 2 Oct 2002 08:25:57 -0700 Received: from Mother2 ([66.156.1.188]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021002152732.BCFH28324.imf13bis.bellsouth.net@Mother2>; Wed, 2 Oct 2002 11:27:32 -0400 Date: Wed, 2 Oct 2002 11:25:39 -0400 From: Greg Freemyer Subject: re: direct io on linux To: Gabor Forgacs , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021002152732.BCFH28324.imf13bis.bellsouth.net@Mother2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g92FPwtG007758 X-archive-position: 699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> Hi all >> What are the possibilities to use direct io on linux with any filesystem ? >> I use xfs/O_DIRECT under irix, i am just wondering is the direct io is a >> viable solution under linux too. Generally what is the fastest disk >> access >> method under linux with raid 0 ? I should read sequentialy 9-12 mb files. >> Thanx I don't know about xfs/linux or any other common linux FS, but I _assume_ the newly GPLed FS from Oracle (OCFS) supports O_DIRECT. http://ocfs.otncast.otnxchange.oracle.com/servlets/ProjectHome Unfortunately you have to join OTN to get access, but it is free, and they rarely if ever send out e-mails. I assume OCFS will start showing up in Redhat Advanced Server at some point. Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:37:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:37:43 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FbVtG009710 for ; Wed, 2 Oct 2002 08:37:31 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 612881472C; Wed, 2 Oct 2002 17:15:34 +0200 (MEST) Date: Wed, 2 Oct 2002 17:15:33 +0200 From: Andi Kleen To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com Subject: Re: direct io on linux Message-ID: <20021002171533.A28084@wotan.suse.de> References: <200210021702.04252.gabor@colorfront.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210021702.04252.gabor@colorfront.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Wed, Oct 02, 2002 at 05:02:04PM +0200, Gabor Forgacs wrote: > I use xfs/O_DIRECT under irix, i am just wondering is the direct io is a > viable solution under linux too. Generally what is the fastest disk access > method under linux with raid 0 ? I should read sequentialy 9-12 mb files. O_DIRECT doesn't do any readahead to keep the disk streaming so unless you're doing it yourself (e.g. by using multiple threads or aio) normal IO will be likely faster. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:38:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:38:46 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FcitG010061 for ; Wed, 2 Oct 2002 08:38:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA59577 for ; Wed, 2 Oct 2002 10:38:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA41830 for ; Wed, 2 Oct 2002 10:38:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92FcH610122; Wed, 2 Oct 2002 10:38:17 -0500 Message-Id: <200210021538.g92FcH610122@jen.americas.sgi.com> Date: Wed, 2 Oct 2002 10:38:17 -0500 Subject: TAKE - XFS part of 2.5.40 merge X-archive-position: 701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fall back to schedule_task from the per cpu io completion threads, this should be temporary. Date: Wed Oct 2 08:38:11 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128890a linux/fs/xfs/xfs_log.c - 1.255 - call schedule_task instead of pagebuf_queue_task linux/fs/xfs/pagebuf/page_buf.c - 1.63 - remove pagebuf io completion threads linux/fs/xfs/pagebuf/page_buf.h - 1.46 - remove pagebuf_queue_task From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:40:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:40:41 -0700 (PDT) Received: from eclectic.kluge.net (IDENT:7JubSgBDcTVfNDO0USbspplvZpjjGJBu@eclectic.kluge.net [66.92.69.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FectG010690 for ; Wed, 2 Oct 2002 08:40:38 -0700 Received: from eclectic.kluge.net (localhost [127.0.0.1]) by eclectic.kluge.net (8.12.6/8.12.6) with ESMTP id g92Febu2009756 for ; Wed, 2 Oct 2002 11:40:37 -0400 Received: (from felicity@localhost) by eclectic.kluge.net (8.12.6/8.12.6/Submit) id g92Feb81009754 for linux-xfs@oss.sgi.com; Wed, 2 Oct 2002 11:40:37 -0400 Date: Wed, 2 Oct 2002 11:40:37 -0400 From: Theo Van Dinter To: linux-xfs@oss.sgi.com Subject: Suggestions for kernel/XFS version? Message-ID: <20021002154037.GD1527@kluge.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZARJHfwaSJQLOEUz" Content-Disposition: inline User-Agent: Mutt/1.4i X-GPG-Keyserver: http://wwwkeys.pgp.net X-GPG-Keynumber: 0xE580B363 X-GPG-Fingerprint: 75B1 F6D0 8368 38E7 A4C5 F6C2 02E3 9051 E580 B363 X-archive-position: 702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felicity@kluge.net Precedence: bulk X-list: linux-xfs --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been using XFS for a while, but find myself in a bit of a quandry about where to go now... A week or two ago, my main server got very flaky (semi-constant rebooting), so I replaced the Athlon UP MB/CPU for a nice Athlon MP version. It came up fine with the kernel at the time (2.4.9-31SGI_XFS_1.1, no data loss or errors), so I upgraded to smp-2.4.18-4SGI_XFS_1.1 to get a recent MP-based kernel. The server has a 3ware RAID controller, and also uses LVM, so I've been paying attention to versions of these drivers. 2.4.18 and previous had old versions of the 3ware driver, so I would compile a new version whenever I changed kernels. This is when I noticed that the UP XFS 2.4.18-4 (could have been XFS 2.4.18 instead) kernel had LVM 1.0.3, whereas SMP XFS 2.4.18-4 has 1.0.1-rc4. I also found that SMP XFS 2.4.18-4 seemed to hit the disk a lot for writes, almost like it had no or only a very small kernel-level write cache/XFS pre-allocation space. (write cache is off on the controller) Since the performance was noticably bad because of this, I switched last night to SMP 2.4.18-SGI_XFS_1.1. This seems to have solved my performance problem, but I now I have 2 new problems. 1) I'm left with LVM 1.0.1-rc4, and 2) I can't compile a new 3w-xxxx driver (the module compiles, but I get "Undefined symbols" when I run the depmod to verify installation). So the quandry is: Where should I go from here? So far, 2.4.18-SGI_XFS_1.1 seems to have solved the performance issue I was seeing, but has old LVM and 3w-xxxxx drivers which I'd like to upgrade. It looks like 2.4.19 has LVM 1.0.3 and the correct 3w-xxxx driver version already. So I could compile up my own kernel, but the only XFS patch I see for 2.4.19 is a CVS snapshot from last week. I'm leary of using a snapshot for an integral part of the kernel, but there doesn't seem to be a 1.1 patch for 2.4.19 (and the 2.4.18 patch seems to be XFS 1.1-PR2). Any thoughts? Thanks. :) --=20 Randomly Generated Tagline: "Now it's time for pay back ... Can someone lend me enough for a Coke?" - Chris Bentley --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9mxN1AuOQUeWAs2MRAiEYAJ45SHnFbUExi+EwPN9giQXxnNvJsACeI1Ep T6HzbZqhk5vrUtCR6sV9+Xs= =Sa6t -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz-- From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:46:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:46:25 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FkKtG011189 for ; Wed, 2 Oct 2002 08:46:20 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA58390 for ; Wed, 2 Oct 2002 10:46:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA30811 for ; Wed, 2 Oct 2002 10:46:05 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92Fjii10196; Wed, 2 Oct 2002 10:45:44 -0500 Message-Id: <200210021545.g92Fjii10196@jen.americas.sgi.com> Date: Wed, 2 Oct 2002 10:45:44 -0500 Subject: TAKE - merge up to 2.5.40 To: linux-xfs@oss.sgi.com X-archive-position: 703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The Linus part of the merge Date: Wed Oct 2 08:42:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128891a linux/sound/sparc/cs4231.c - 1.1 linux/drivers/usb/core/driverfs.c - 1.1 linux/sound/sparc/amd7930.c - 1.1 linux/Documentation/cpufreq - 1.1 linux/drivers/usb/core/usb.h - 1.1 linux/sound/sparc/Makefile - 1.1 linux/fs/smbfs/symlink.c - 1.1 linux/include/asm-alpha/topology.h - 1.1 linux/include/asm-arm/kmap_types.h - 1.1 linux/sound/sparc/Config.in - 1.1 linux/drivers/isdn/i4l/isdn_ciscohdlck.h - 1.1 linux/drivers/isdn/i4l/isdn_ciscohdlck.c - 1.1 linux/sound/pci/cs46xx/imgs/cwcsnoop.h - 1.1 linux/sound/pci/cs46xx/imgs/cwcemb80.h - 1.1 linux/Documentation/sparc/README-2.5 - 1.1 linux/Documentation/vm/hugetlbpage.txt - 1.1 linux/include/asm-arm/percpu.h - 1.1 linux/include/asm-arm/topology.h - 1.1 linux/include/asm-cris/topology.h - 1.1 linux/sound/pci/cs46xx/imgs/cwcbinhack.h - 1.1 linux/include/asm-generic/topology.h - 1.1 linux/sound/pci/cs46xx/imgs/cwcasync.h - 1.1 linux/sound/pci/cs46xx/imgs/cwc4630.h - 1.1 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.1 linux/include/asm-i386/topology.h - 1.1 linux/include/asm-ia64/topology.h - 1.1 linux/include/asm-m68k/topology.h - 1.1 linux/sound/pci/cs46xx/dsp_spos.h - 1.1 linux/include/asm-mips/topology.h - 1.1 linux/sound/pci/cs46xx/dsp_spos.c - 1.1 linux/include/asm-mips64/topology.h - 1.1 linux/include/asm-parisc/topology.h - 1.1 linux/sound/pci/cs46xx/cs46xx_lib.h - 1.1 linux/include/asm-ppc/topology.h - 1.1 linux/include/asm-ppc64/topology.h - 1.1 linux/sound/pci/ac97/ac97_patch.h - 1.1 linux/include/asm-s390/topology.h - 1.1 linux/include/asm-s390x/topology.h - 1.1 linux/include/asm-sh/topology.h - 1.1 linux/sound/pci/ac97/ac97_patch.c - 1.1 linux/include/asm-sparc/topology.h - 1.1 linux/sound/pci/ac97/ac97_id.h - 1.1 linux/sound/isa/dt019x.c - 1.1 linux/sound/core/pcm_sgbuf.c - 1.1 linux/arch/arm/mach-arc/Config.help - 1.1 linux/arch/arm/mach-arc/Config.in - 1.1 linux/arch/arm/mach-clps711x/Config.help - 1.1 linux/arch/arm/mach-clps711x/Config.in - 1.1 linux/kernel/cpufreq.c - 1.1 linux/arch/arm/mach-clps711x/ceiva.c - 1.1 linux/include/asm-x86_64/topology.h - 1.1 linux/arch/arm/mach-epxa10db/Config.help - 1.1 linux/arch/arm/mach-epxa10db/Config.in - 1.1 linux/arch/arm/mach-footbridge/Config.help - 1.1 linux/arch/arm/mach-footbridge/Config.in - 1.1 linux/arch/arm/mach-sa1100/Config.help - 1.1 linux/net/llc/af_llc.c - 1.1 linux/include/sound/pcm_sgbuf.h - 1.1 linux/include/sound/cs46xx_dsp_task_types.h - 1.1 linux/include/sound/cs46xx_dsp_spos.h - 1.1 linux/include/sound/cs46xx_dsp_scb_types.h - 1.1 linux/arch/arm/mach-iop310/Config.help - 1.1 linux/arch/arm/mach-iop310/Config.in - 1.1 linux/arch/um/uml.lds.S - 1.1 linux/arch/arm/mach-pxa/Config.in - 1.1 linux/include/asm-um/fixmap.h - 1.1 linux/include/linux/cpufreq.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.1 linux/arch/arm/mach-sa1100/Config.in - 1.1 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.1 linux/include/asm-sparc64/topology.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.1 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.1 linux/scripts/Configure - 1.17 linux/net/x25/x25_timer.c - 1.8 linux/net/x25/x25_subr.c - 1.8 linux/net/x25/x25_route.c - 1.9 linux/net/x25/x25_out.c - 1.9 linux/net/x25/x25_link.c - 1.12 linux/net/x25/x25_in.c - 1.12 linux/net/x25/x25_facilities.c - 1.7 linux/net/x25/x25_dev.c - 1.10 linux/net/x25/af_x25.c - 1.30 linux/net/sunrpc/svc.c - 1.14 linux/net/sunrpc/sched.c - 1.32 linux/net/sunrpc/clnt.c - 1.23 linux/net/lapb/lapb_timer.c - 1.6 linux/net/lapb/lapb_subr.c - 1.5 linux/net/lapb/lapb_out.c - 1.4 linux/net/lapb/lapb_in.c - 1.5 linux/net/lapb/lapb_iface.c - 1.12 linux/net/ipv6/ndisc.c - 1.25 linux/net/ipv6/ip6_fib.c - 1.11 linux/net/ipv6/addrconf.c - 1.26 linux/net/ipv4/proc.c - 1.13 linux/net/core/dev.c - 1.61 linux/net/Makefile - 1.26 linux/net/Config.in - 1.29 linux/mm/vmscan.c - 1.115 linux/mm/swap_state.c - 1.50 linux/mm/slab.c - 1.42 linux/mm/page_alloc.c - 1.94 linux/mm/mremap.c - 1.35 linux/mm/mmap.c - 1.61 linux/mm/memory.c - 1.94 linux/kernel/softirq.c - 1.30 linux/kernel/signal.c - 1.43 linux/kernel/sched.c - 1.84 linux/kernel/ksyms.c - 1.168 linux/kernel/kmod.c - 1.25 linux/kernel/fork.c - 1.72 linux/kernel/Makefile - 1.36 linux/include/scsi/sg.h - 1.17 linux/include/net/x25.h - 1.12 linux/include/net/sock.h - 1.34 linux/include/net/lapb.h - 1.3 linux/include/linux/tty_flip.h - 1.4 linux/include/linux/tqueue.h - 1.13 linux/include/linux/timer.h - 1.16 linux/include/linux/swap.h - 1.65 linux/include/linux/smbno.h - 1.6 linux/include/linux/smb_fs.h - 1.21 linux/include/linux/smb.h - 1.9 linux/include/linux/slab.h - 1.25 linux/include/linux/sched.h - 1.86 linux/include/linux/msdos_fs.h - 1.22 linux/include/linux/module.h - 1.36 linux/include/linux/loop.h - 1.9 linux/include/linux/isdn_ppp.h - 1.11 linux/include/linux/isdn.h - 1.26 linux/include/linux/interrupt.h - 1.24 linux/include/linux/genhd.h - 1.26 linux/include/linux/blkdev.h - 1.71 linux/include/linux/auto_fs.h - 1.10 linux/include/asm-sparc64/irq.h - 1.13 linux/include/asm-sparc64/floppy.h - 1.16 linux/include/asm-sparc64/ebus.h - 1.5 linux/include/asm-sparc64/bitops.h - 1.16 linux/include/asm-sparc64/audioio.h - 1.10 linux/include/asm-sparc/irq.h - 1.10 linux/include/asm-sparc/bitops.h - 1.16 linux/include/asm-sparc/audioio.h - 1.11 linux/include/asm-i386/msr.h - 1.14 linux/include/asm-arm/unistd.h - 1.23 linux/include/asm-arm/system.h - 1.23 linux/include/asm-arm/stat.h - 1.7 linux/include/asm-arm/setup.h - 1.14 linux/include/asm-arm/procinfo.h - 1.11 linux/include/asm-arm/processor.h - 1.24 linux/include/asm-arm/proc-armv/processor.h - 1.11 linux/include/asm-arm/proc-armv/elf.h - 1.6 linux/include/asm-arm/mmu_context.h - 1.13 linux/include/asm-arm/ide.h - 1.7 linux/include/asm-arm/elf.h - 1.6 linux/include/asm-arm/arch-rpc/memory.h - 1.8 linux/include/asm-arm/arch-rpc/keyboard.h - 1.6 linux/include/asm-arm/arch-nexuspci/memory.h - 1.8 linux/include/asm-arm/arch-ebsa285/memory.h - 1.11 linux/include/asm-arm/arch-ebsa285/keyboard.h - 1.8 linux/include/asm-arm/arch-ebsa110/memory.h - 1.9 linux/include/asm-arm/arch-arc/memory.h - 1.8 linux/fs/vfat/namei.c - 1.33 linux/fs/umsdos/Makefile - 1.8 linux/fs/ufs/symlink.c - 1.9 linux/fs/ufs/super.c - 1.36 linux/fs/ufs/namei.c - 1.19 linux/fs/ufs/inode.c - 1.25 linux/fs/ufs/file.c - 1.14 linux/fs/ufs/dir.c - 1.20 linux/fs/smbfs/proc.c - 1.23 linux/fs/smbfs/inode.c - 1.41 linux/fs/smbfs/dir.c - 1.25 linux/fs/smbfs/Makefile - 1.10 linux/fs/romfs/inode.c - 1.39 linux/fs/proc/root.c - 1.30 linux/fs/proc/kmsg.c - 1.9 linux/fs/proc/inode.c - 1.26 linux/fs/proc/generic.c - 1.32 linux/fs/proc/base.c - 1.43 linux/fs/proc/array.c - 1.49 linux/fs/nfsd/nfssvc.c - 1.25 linux/fs/ncpfs/symlink.c - 1.19 linux/fs/ncpfs/sock.c - 1.14 linux/fs/minix/namei.c - 1.22 linux/fs/minix/inode.c - 1.36 linux/fs/minix/file.c - 1.18 linux/fs/minix/dir.c - 1.15 linux/fs/lockd/svc.c - 1.21 linux/fs/lockd/clntproc.c - 1.17 linux/fs/isofs/rock.c - 1.23 linux/fs/isofs/inode.c - 1.39 linux/fs/isofs/dir.c - 1.18 linux/fs/file_table.c - 1.23 linux/fs/exec.c - 1.68 linux/fs/devpts/inode.c - 1.19 linux/fs/block_dev.c - 1.63 linux/fs/autofs/waitq.c - 1.7 linux/drivers/scsi/st.c - 1.52 linux/drivers/scsi/sr.c - 1.53 linux/drivers/scsi/sg.c - 1.38 linux/drivers/scsi/sd.c - 1.72 linux/drivers/scsi/scsi_error.c - 1.30 linux/drivers/scsi/scsi.h - 1.33 linux/drivers/scsi/scsi.c - 1.59 linux/drivers/scsi/hosts.h - 1.24 linux/drivers/scsi/hosts.c - 1.31 linux/drivers/sbus/audio/dummy.h - 1.4 linux/drivers/sbus/audio/dmy.c - 1.10 linux/drivers/sbus/audio/dbri.h - 1.5 linux/drivers/sbus/audio/dbri.c - 1.15 linux/drivers/sbus/audio/cs4231.h - 1.5 linux/drivers/sbus/audio/cs4231.c - 1.14 linux/drivers/sbus/audio/cs4215.h - 1.5 linux/drivers/sbus/audio/audio.c - 1.20 linux/drivers/sbus/audio/amd7930.h - 1.4 linux/drivers/sbus/audio/amd7930.c - 1.12 linux/drivers/sbus/audio/Makefile - 1.7 linux/drivers/sbus/audio/Config.in - 1.6 linux/drivers/pci/quirks.c - 1.31 linux/drivers/net/via-rhine.c - 1.37 linux/drivers/net/tlan.c - 1.30 linux/drivers/net/ni65.c - 1.17 linux/drivers/net/hamradio/scc.c - 1.27 linux/drivers/net/ethertap.c - 1.13 linux/drivers/net/epic100.c - 1.33 linux/drivers/net/eepro100.c - 1.50 linux/drivers/net/at1700.c - 1.21 linux/drivers/net/acenic.h - 1.22 linux/drivers/net/Makefile - 1.62 linux/drivers/net/3c509.c - 1.34 linux/drivers/net/3c505.c - 1.29 linux/drivers/macintosh/adb.c - 1.18 linux/drivers/char/tty_io.c - 1.54 linux/drivers/char/random.c - 1.31 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.7 linux/drivers/cdrom/sonycd535.c - 1.29 linux/drivers/cdrom/sjcd.c - 1.22 linux/drivers/cdrom/sbpcd.c - 1.29 linux/drivers/cdrom/optcd.c - 1.23 linux/drivers/cdrom/mcdx.c - 1.20 linux/drivers/cdrom/mcd.c - 1.23 linux/drivers/cdrom/gscd.c - 1.23 linux/drivers/cdrom/cm206.c - 1.24 linux/drivers/cdrom/cdu31a.c - 1.23 linux/drivers/cdrom/aztcd.c - 1.25 linux/drivers/block/z2ram.c - 1.19 linux/drivers/block/xd.c - 1.46 linux/drivers/block/swim3.c - 1.21 linux/drivers/block/rd.c - 1.61 linux/drivers/block/ps2esdi.c - 1.48 linux/drivers/block/paride/pf.c - 1.29 linux/drivers/block/paride/pd.c - 1.38 linux/drivers/block/paride/pcd.c - 1.25 linux/drivers/block/nbd.c - 1.44 linux/drivers/block/loop.c - 1.68 linux/drivers/block/ll_rw_blk.c - 1.116 linux/drivers/block/genhd.c - 1.35 linux/drivers/block/floppy.c - 1.52 linux/drivers/block/ataflop.c - 1.28 linux/drivers/block/amiflop.c - 1.29 linux/drivers/block/acsi.c - 1.38 linux/drivers/acorn/block/mfmhd.c - 1.31 linux/drivers/acorn/block/fd1772.c - 1.22 linux/arch/sparc64/solaris/signal.c - 1.6 linux/arch/sparc64/kernel/time.c - 1.24 linux/arch/sparc64/kernel/sys_sunos32.c - 1.40 linux/arch/sparc64/kernel/sys_sparc32.c - 1.58 linux/arch/sparc64/kernel/signal32.c - 1.27 linux/arch/sparc64/kernel/signal.c - 1.25 linux/arch/sparc64/kernel/irq.c - 1.29 linux/arch/sparc64/kernel/ebus.c - 1.17 linux/arch/sparc64/kernel/Makefile - 1.26 linux/arch/sparc64/defconfig - 1.78 linux/arch/sparc64/config.in - 1.62 linux/arch/sparc/mm/srmmu.c - 1.39 linux/arch/sparc/kernel/time.c - 1.20 linux/arch/sparc/kernel/sys_sunos.c - 1.38 linux/arch/sparc/kernel/sun4m_irq.c - 1.11 linux/arch/sparc/kernel/sun4c_irq.c - 1.9 linux/arch/sparc/kernel/signal.c - 1.28 linux/arch/sparc/kernel/irq.c - 1.24 linux/arch/sparc/defconfig - 1.36 linux/arch/sparc/config.in - 1.45 linux/arch/sparc/boot/Makefile - 1.7 linux/arch/sparc/Makefile - 1.17 linux/arch/ppc/Makefile - 1.30 linux/arch/mips/kernel/time.c - 1.13 linux/arch/m68k/atari/stram.c - 1.19 linux/arch/i386/mm/fault.c - 1.28 linux/arch/i386/kernel/vm86.c - 1.19 linux/arch/i386/kernel/time.c - 1.28 linux/arch/i386/kernel/signal.c - 1.29 linux/arch/i386/kernel/irq.c - 1.48 linux/arch/i386/kernel/i386_ksyms.c - 1.57 linux/arch/i386/config.in - 1.93 linux/arch/arm/mm/init.c - 1.33 linux/arch/arm/mm/fault-common.c - 1.24 linux/arch/arm/lib/Makefile - 1.23 linux/arch/arm/kernel/sys_arm.c - 1.21 linux/arch/arm/kernel/signal.c - 1.26 linux/arch/arm/kernel/setup.c - 1.35 linux/arch/arm/kernel/ptrace.c - 1.21 linux/arch/arm/kernel/process.c - 1.30 linux/arch/arm/kernel/irq.c - 1.23 linux/arch/arm/kernel/init_task.c - 1.11 linux/arch/arm/kernel/entry-armv.S - 1.35 linux/arch/arm/kernel/armksyms.c - 1.29 linux/arch/arm/config.in - 1.46 linux/arch/arm/boot/compressed/head.S - 1.21 linux/arch/arm/boot/Makefile - 1.19 linux/Rules.make - 1.31 linux/Makefile - 1.221 linux/MAINTAINERS - 1.119 linux/Documentation/scsi.txt - 1.4 linux/Documentation/scsi-generic.txt - 1.10 linux/Documentation/networking/ip-sysctl.txt - 1.13 linux/Documentation/networking/00-INDEX - 1.6 linux/Documentation/kernel-docs.txt - 1.9 linux/Documentation/filesystems/isofs.txt - 1.3 linux/Documentation/Changes - 1.55 linux/CREDITS - 1.88 linux/fs/efs/symlink.c - 1.13 linux/fs/efs/super.c - 1.17 linux/fs/efs/inode.c - 1.12 linux/fs/efs/dir.c - 1.12 linux/drivers/block/blkpg.c - 1.28 linux/arch/arm/nwfpe/fpopcode.h - 1.4 linux/arch/arm/nwfpe/fpmodule.c - 1.12 linux/arch/arm/nwfpe/fpa11.h - 1.6 linux/arch/arm/nwfpe/fpa11.c - 1.10 linux/arch/arm/nwfpe/entry26.S - 1.7 linux/arch/arm/nwfpe/entry.S - 1.7 linux/drivers/tc/zs.h - 1.4 linux/drivers/block/cpqarray.c - 1.57 linux/include/asm-sparc64/parport.h - 1.11 linux/fs/partitions/sun.c - 1.7 linux/fs/partitions/check.c - 1.54 linux/drivers/pnp/isapnp.c - 1.29 linux/drivers/net/sis900.c - 1.36 linux/drivers/atm/zatm.c - 1.14 linux/drivers/atm/nicstar.c - 1.18 linux/drivers/atm/horizon.c - 1.13 linux/drivers/atm/eni.c - 1.18 linux/drivers/atm/atmtcp.c - 1.10 linux/drivers/atm/ambassador.c - 1.16 linux/drivers/block/DAC960.c - 1.57 linux/arch/sparc64/kernel/power.c - 1.11 linux/drivers/pcmcia/Makefile - 1.20 linux/drivers/pcmcia/Config.in - 1.14 linux/drivers/block/swim_iop.c - 1.16 linux/drivers/net/starfire.c - 1.27 linux/drivers/net/tokenring/olympic.c - 1.22 linux/include/linux/pci_ids.h - 1.75 linux/drivers/net/wan/lapbether.c - 1.13 linux/include/asm-arm/pci.h - 1.20 linux/include/asm-arm/arch-sa1100/irqs.h - 1.11 linux/fs/proc/proc_misc.c - 1.43 linux/fs/bfs/inode.c - 1.27 linux/fs/bfs/file.c - 1.23 linux/fs/bfs/dir.c - 1.23 linux/fs/proc/kcore.c - 1.13 linux/drivers/net/sis900.h - 1.13 linux/drivers/net/sk98lin/Makefile - 1.6 linux/include/asm-arm/arch-cl7500/memory.h - 1.5 linux/include/linux/mmzone.h - 1.28 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.15 linux/kernel/timer.c - 1.31 linux/drivers/scsi/scsi_merge.c - 1.41 linux/drivers/sbus/char/jsflash.c - 1.23 linux/fs/openpromfs/inode.c - 1.25 linux/fs/cramfs/inode.c - 1.31 linux/drivers/net/arcnet/arcnet.c - 1.14 linux/arch/arm/lib/findbit.S - 1.7 linux/arch/arm/lib/strchr.S - 1.4 linux/arch/i386/kernel/mpparse.c - 1.27 linux/fs/autofs4/waitq.c - 1.8 linux/drivers/net/8139too.c - 1.44 linux/arch/arm/mm/consistent.c - 1.12 linux/fs/devfs/base.c - 1.44 linux/drivers/net/skfp/Makefile - 1.5 linux/drivers/net/skfp/skfddi.c - 1.13 linux/net/bridge/br_input.c - 1.12 linux/drivers/video/matrox/Makefile - 1.7 linux/include/asm-mips64/mmzone.h - 1.10 linux/drivers/atm/fore200e.c - 1.16 linux/include/asm-arm/arch-nexuspci/keyboard.h - 1.3 linux/include/linux/usb.h - 1.47 linux/drivers/ide/ide.c - 1.70 linux/drivers/ide/ide-probe.c - 1.40 linux/include/linux/usbdevice_fs.h - 1.10 linux/include/asm-arm/arch-shark/memory.h - 1.7 linux/fs/ramfs/inode.c - 1.31 linux/drivers/video/sa1100fb.c - 1.16 linux/drivers/usb/serial/ftdi_sio.c - 1.41 linux/drivers/usb/serial/usbserial.c - 1.43 linux/drivers/usb/serial/whiteheat.c - 1.31 linux/drivers/usb/serial/visor.h - 1.11 linux/drivers/usb/serial/visor.c - 1.41 linux/drivers/usb/serial/omninet.c - 1.29 linux/drivers/net/wan/lmc/lmc_var.h - 1.5 linux/drivers/net/wan/lmc/Makefile - 1.5 linux/drivers/s390/block/dasd.c - 1.29 linux/drivers/s390/block/dasd_proc.c - 1.7 linux/include/asm-arm/arch-l7200/memory.h - 1.5 linux/drivers/usb/storage/usb.c - 1.30 linux/drivers/usb/storage/transport.c - 1.29 linux/drivers/usb/serial/keyspan.c - 1.33 linux/include/asm-arm/memory.h - 1.7 linux/arch/arm/kernel/ptrace.h - 1.4 linux/fs/jffs/intrep.c - 1.15 linux/drivers/mtd/ftl.c - 1.25 linux/drivers/mtd/mtdblock.c - 1.23 linux/fs/smbfs/ChangeLog - 1.10 linux/drivers/media/video/saa5249.c - 1.10 linux/arch/arm/boot/bootp/Makefile - 1.5 linux/arch/arm/boot/bootp/bootp.lds - 1.3 linux/arch/arm/boot/bootp/init.S - 1.6 linux/drivers/char/i810-tco.h - 1.3 linux/drivers/char/i810-tco.c - 1.11 linux/arch/arm/tools/mach-types - 1.19 linux/drivers/md/raid5.c - 1.35 linux/arch/arm/kernel/plx90x0.c - 1.3 linux/arch/arm/kernel/via82c505.c - 1.7 linux/arch/arm/mach-sa1100/Makefile - 1.14 linux/arch/arm/mach-sa1100/leds.c - 1.9 linux/drivers/block/cciss.c - 1.44 linux/drivers/block/cciss.h - 1.14 linux/drivers/char/toshiba.c - 1.6 linux/drivers/md/md.c - 1.58 linux/drivers/net/hamachi.c - 1.17 linux/drivers/net/sundance.c - 1.19 linux/include/asm-arm/arch-tbox/keyboard.h - 1.3 linux/include/asm-arm/arch-tbox/memory.h - 1.4 linux/kernel/context.c - 1.9 linux/drivers/usb/serial/mct_u232.c - 1.24 linux/drivers/usb/serial/empeg.c - 1.29 linux/Documentation/DocBook/sis900.tmpl - 1.2 linux/arch/sparc64/kernel/pci_schizo.c - 1.17 linux/fs/reiserfs/journal.c - 1.34 linux/include/linux/reiserfs_fs.h - 1.32 linux/drivers/s390/block/xpram.c - 1.26 linux/Documentation/i810_rng.txt - 1.5 linux/include/asm-arm/mach/amba_kmi.h - 1.3 linux/include/asm-arm/arch-integrator/memory.h - 1.3 linux/include/asm-arm/arch-integrator/keyboard.h - 1.4 linux/arch/arm/mach-integrator/Makefile - 1.5 linux/arch/arm/mach-integrator/arch.c - 1.7 linux/arch/arm/mach-integrator/pci_v3.c - 1.11 linux/Documentation/s390/Debugging390.txt - 1.5 linux/include/asm-alpha/mmzone.h - 1.5 linux/drivers/net/fealnx.c - 1.15 linux/drivers/net/wireless/airport.c - 1.9 linux/drivers/net/wireless/hermes.h - 1.10 linux/drivers/net/wireless/orinoco.c - 1.11 linux/drivers/net/wireless/orinoco.h - 1.9 linux/drivers/net/wireless/orinoco_cs.c - 1.11 linux/include/linux/mii.h - 1.6 linux/drivers/bluetooth/hci_usb.c - 1.12 linux/drivers/mtd/nftlcore.c - 1.24 linux/drivers/mtd/nand/nand_ecc.c - 1.4 linux/drivers/mtd/mtdblock_ro.c - 1.13 linux/drivers/net/wireless/airo.c - 1.21 linux/drivers/usb/serial/cyberjack.c - 1.18 linux/drivers/usb/serial/pl2303.c - 1.20 linux/drivers/video/sa1100fb.h - 1.5 linux/arch/arm/mach-sa1100/yopy.c - 1.7 linux/arch/arm/mach-sa1100/xp860.c - 1.9 linux/arch/arm/mach-sa1100/simpad.c - 1.11 linux/arch/arm/mach-sa1100/sa1111.h - 1.6 linux/arch/arm/mach-sa1100/sa1111.c - 1.10 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.4 linux/arch/arm/kernel/compat.c - 1.5 linux/include/asm-arm/arch-anakin/keyboard.h - 1.3 linux/include/asm-arm/arch-anakin/memory.h - 1.2 linux/arch/arm/mach-sa1100/pfs168.c - 1.11 linux/arch/arm/mach-sa1100/pcipool.h - 1.2 linux/arch/arm/mach-sa1100/pcipool.c - 1.2 linux/arch/arm/mach-sa1100/omnimeter.c - 1.9 linux/arch/arm/mach-sa1100/neponset.c - 1.12 linux/arch/arm/mach-sa1100/jornada720.c - 1.9 linux/arch/arm/mach-integrator/cpu.c - 1.6 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.9 linux/arch/arm/mach-sa1100/assabet.c - 1.13 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.6 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.8 linux/arch/arm/mach-sa1100/generic.h - 1.4 linux/arch/arm/mach-sa1100/generic.c - 1.10 linux/arch/arm/mach-sa1100/freebird.c - 1.10 linux/arch/arm/mach-sa1100/flexanet.c - 1.8 linux/drivers/tc/lk201-map.map - 1.2 linux/drivers/tc/lk201-remap.c - 1.2 linux/drivers/scsi/53c700.c - 1.10 linux/fs/jffs2/background.c - 1.11 linux/lib/bust_spinlocks.c - 1.2 linux/fs/smbfs/proto.h - 1.6 linux/drivers/mtd/devices/blkmtd.c - 1.14 linux/drivers/net/wireless/orinoco_plx.c - 1.7 linux/drivers/usb/serial/ir-usb.c - 1.20 linux/drivers/pcmcia/sa1100_generic.c - 1.9 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.3 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.3 linux/drivers/pcmcia/sa1100_jornada720.c - 1.3 linux/drivers/pcmcia/sa1100_neponset.c - 1.5 linux/drivers/pcmcia/sa1100_pfs168.c - 1.3 linux/drivers/pcmcia/sa1100_xp860.c - 1.3 linux/include/asm-arm/arch-sa1100/h3600.h - 1.3 linux/arch/arm/mach-sa1100/h3600.c - 1.11 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.14 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.12 linux/arch/arm/lib/kbd.c - 1.3 linux/drivers/message/i2o/i2o_block.c - 1.22 linux/drivers/net/8139cp.c - 1.21 linux/drivers/atm/lanai.c - 1.3 linux/fs/isofs/compress.c - 1.10 linux/include/asm-arm/arch-epxa10db/memory.h - 1.2 linux/arch/arm/mach-sa1100/pm.c - 1.7 linux/drivers/atm/idt77252.c - 1.6 linux/fs/jbd/journal.c - 1.15 linux/drivers/scsi/sym53c8xx_2/Makefile - 1.4 linux/fs/driverfs/inode.c - 1.23 linux/include/linux/gfp.h - 1.5 linux/drivers/usb/serial/ipaq.c - 1.14 linux/drivers/usb/serial/kl5kusb105.c - 1.13 linux/arch/arm/mm/minicache.c - 1.6 linux/arch/arm/mm/alignment.c - 1.5 linux/arch/arm/mach-sa1100/system3.c - 1.12 linux/include/asm-arm/hardware/sa1111.h - 1.6 linux/include/asm-arm/arch-adifcc/memory.h - 1.2 linux/include/asm-arm/arch-iop310/memory.h - 1.3 linux/arch/arm/mach-clps711x/Makefile - 1.5 linux/arch/arm/mach-clps711x/p720t-leds.c - 1.2 linux/include/asm-arm/arch-clps711x/hardware.h - 1.2 linux/arch/arm/mach-iop310/iop310-pci.c - 1.5 linux/arch/arm/mach-rpc/riscpc.c - 1.5 linux/include/asm-arm/arch-clps711x/memory.h - 1.5 linux/arch/arm/mach-sa1100/dma.c - 1.2 linux/arch/arm/mach-ftvpci/leds.c - 1.2 linux/arch/arm/mach-footbridge/dc21285.c - 1.3 linux/arch/arm/kernel/head.S - 1.6 linux/include/linux/init_task.h - 1.14 linux/arch/arm/Config.help - 1.9 linux/arch/i386/Config.help - 1.14 linux/drivers/sbus/audio/Config.help - 1.2 linux/drivers/ide/Config.help - 1.16 linux/drivers/net/mii.c - 1.5 linux/sound/pci/ymfpci/ymfpci_main.c - 1.6 linux/sound/pci/ymfpci/ymfpci.c - 1.8 linux/sound/pci/via8233.c - 1.9 linux/sound/pci/via686.c - 1.8 linux/sound/pci/rme9652/rme9652.c - 1.9 linux/sound/pci/rme96.c - 1.8 linux/sound/pci/nm256/nm256.c - 1.8 linux/sound/pci/maestro3.c - 1.8 linux/sound/pci/korg1212/korg1212.c - 1.9 linux/sound/pci/intel8x0.c - 1.9 linux/sound/pci/ice1712.c - 1.9 linux/sound/pci/es1968.c - 1.8 linux/sound/pci/ens1370.c - 1.8 linux/sound/pci/emu10k1/memory.c - 1.4 linux/sound/pci/emu10k1/emupcm.c - 1.6 linux/sound/pci/emu10k1/emumpu401.c - 1.4 linux/sound/pci/emu10k1/emufx.c - 1.6 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.6 linux/sound/pci/cs46xx/cs46xx_image.h - 1.2 linux/sound/pci/cs46xx/cs46xx.c - 1.11 linux/sound/pci/cs46xx/Makefile - 1.4 linux/sound/pci/cs4281.c - 1.9 linux/sound/pci/ali5451/ali5451.c - 1.8 linux/sound/pci/ac97/ac97_codec.c - 1.7 linux/sound/pci/ac97/Makefile - 1.7 linux/sound/pci/Config.in - 1.6 linux/sound/oss/wf_midi.c - 1.2 linux/sound/oss/v_midi.h - 1.2 linux/sound/oss/ics2101.c - 1.2 linux/sound/oss/gus_wave.c - 1.3 linux/sound/oss/gus_midi.c - 1.2 linux/sound/oss/dmasound/dmasound_q40.c - 1.3 linux/sound/oss/dmasound/dmasound_core.c - 1.3 linux/sound/oss/dmasound/dmasound_awacs.c - 1.3 linux/sound/oss/dmasound/dmasound_atari.c - 1.3 linux/sound/oss/dmasound/dmasound.h - 1.2 linux/sound/oss/audio.c - 1.3 linux/sound/isa/wavefront/wavefront.c - 1.6 linux/sound/isa/sb/sb_mixer.c - 1.3 linux/sound/isa/sb/sb_common.c - 1.6 linux/sound/isa/sb/sb16.c - 1.6 linux/sound/isa/sb/Makefile - 1.8 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.5 linux/sound/isa/opl3sa2.c - 1.7 linux/sound/isa/gus/gus_pcm.c - 1.4 linux/sound/isa/gus/gus_mem_proc.c - 1.3 linux/sound/isa/es18xx.c - 1.6 linux/sound/isa/dt0197h.c - 1.6 linux/sound/isa/cs423x/cs4236.c - 1.8 linux/sound/isa/cs423x/cs4231_lib.c - 1.5 linux/sound/isa/ad1848/ad1848_lib.c - 1.6 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.4 linux/sound/isa/Makefile - 1.7 linux/sound/isa/Config.in - 1.4 linux/sound/i2c/i2c.c - 1.3 linux/sound/drivers/serial-u16550.c - 1.7 linux/sound/drivers/opl3/Makefile - 1.7 linux/sound/drivers/mpu401/Makefile - 1.7 linux/sound/core/timer.c - 1.5 linux/sound/core/sound.c - 1.7 linux/sound/core/seq/seq_virmidi.c - 1.6 linux/sound/core/seq/seq_timer.h - 1.3 linux/sound/core/seq/seq_timer.c - 1.4 linux/sound/core/seq/seq_queue.c - 1.7 linux/sound/core/seq/seq_prioq.h - 1.2 linux/sound/core/seq/seq_prioq.c - 1.3 linux/sound/core/seq/seq_midi_event.c - 1.7 linux/sound/core/seq/seq_midi_emul.c - 1.3 linux/sound/core/seq/seq_midi.c - 1.7 linux/sound/core/seq/seq_memory.c - 1.4 linux/sound/core/seq/seq_clientmgr.h - 1.4 linux/sound/core/seq/seq_clientmgr.c - 1.7 linux/sound/core/seq/seq.c - 1.2 linux/sound/core/seq/oss/Makefile - 1.6 linux/sound/core/seq/instr/Makefile - 1.8 linux/sound/core/seq/Makefile - 1.12 linux/sound/core/rtctimer.c - 1.10 linux/sound/core/rawmidi.c - 1.7 linux/sound/core/pcm_native.c - 1.7 linux/sound/core/pcm_misc.c - 1.3 linux/sound/core/pcm_memory.c - 1.3 linux/sound/core/pcm_lib.c - 1.6 linux/sound/core/pcm.c - 1.5 linux/sound/core/oss/pcm_plugin.h - 1.2 linux/sound/core/oss/pcm_plugin.c - 1.3 linux/sound/core/oss/pcm_oss.c - 1.8 linux/sound/core/oss/mixer_oss.c - 1.3 linux/sound/core/oss/io.c - 1.3 linux/sound/core/memory.c - 1.9 linux/sound/core/device.c - 1.6 linux/sound/core/control.c - 1.5 linux/sound/core/Makefile - 1.12 linux/sound/Makefile - 1.10 linux/sound/Config.in - 1.4 linux/include/sound/ymfpci.h - 1.4 linux/include/sound/version.h - 1.9 linux/include/sound/sndmagic.h - 1.4 linux/include/sound/seq_virmidi.h - 1.2 linux/include/sound/sb.h - 1.2 linux/include/sound/rawmidi.h - 1.4 linux/include/sound/pcm_params.h - 1.5 linux/include/sound/pcm.h - 1.5 linux/include/sound/info.h - 1.3 linux/include/sound/emu10k1.h - 1.6 linux/include/sound/driver.h - 1.4 linux/include/sound/cs46xx.h - 1.4 linux/include/sound/core.h - 1.10 linux/include/sound/asound.h - 1.8 linux/include/sound/asequencer.h - 1.3 linux/include/sound/ac97_codec.h - 1.6 linux/arch/arm/mm/abort-lv4t.S - 1.5 linux/arch/arm/mach-sa1100/stork.c - 1.4 linux/fs/jfs/jfs_logmgr.c - 1.20 linux/fs/jfs/jfs_txnmgr.c - 1.17 linux/arch/arm/mach-sa1100/badge4.c - 1.8 linux/sound/pci/Config.help - 1.4 linux/sound/isa/Config.help - 1.2 linux/sound/core/ioctl32/timer32.c - 1.3 linux/sound/core/ioctl32/rawmidi32.c - 1.3 linux/drivers/pcmcia/sa1111_generic.c - 1.3 linux/drivers/pcmcia/sa1100_system3.c - 1.2 linux/drivers/net/tulip/winbond-840.c - 1.5 linux/drivers/pcmcia/sa1100_badge4.c - 1.3 linux/sound/core/ioctl32/pcm32.c - 1.3 linux/sound/core/ioctl32/ioctl32.h - 1.2 linux/sound/core/ioctl32/ioctl32.c - 1.4 linux/sound/core/ioctl32/Makefile - 1.5 linux/Documentation/sound/oss/PAS16 - 1.2 linux/kernel/futex.c - 1.9 linux/Documentation/sound/alsa/serial-u16550.txt - 1.2 linux/sound/core/ioctl32/seq32.c - 1.2 linux/drivers/net/tc35815.c - 1.4 linux/drivers/usb/class/bluetty.c - 1.9 linux/drivers/usb/class/cdc-acm.c - 1.8 linux/drivers/usb/core/Makefile - 1.9 linux/drivers/usb/core/devio.c - 1.9 linux/drivers/usb/core/hcd.c - 1.12 linux/drivers/usb/core/hub.c - 1.11 linux/include/asm-arm/arch-pxa/memory.h - 1.2 linux/include/asm-arm/arch-pxa/idp.h - 1.2 linux/drivers/usb/core/usb.c - 1.17 linux/arch/arm/mach-pxa/dma.c - 1.2 linux/arch/arm/mach-pxa/idp.c - 1.5 linux/drivers/usb/host/ehci-hcd.c - 1.10 linux/drivers/usb/host/ehci-q.c - 1.11 linux/drivers/usb/host/ohci-hcd.c - 1.12 linux/drivers/usb/host/ohci-mem.c - 1.5 linux/drivers/usb/host/ohci-q.c - 1.13 linux/fs/nls/nls_cp1250.c - 1.3 linux/mm/pdflush.c - 1.8 linux/drivers/isdn/i4l/isdn_ppp.h - 1.2 linux/drivers/isdn/i4l/isdn_ppp.c - 1.8 linux/drivers/isdn/i4l/isdn_net.h - 1.6 linux/drivers/isdn/i4l/isdn_net.c - 1.6 linux/drivers/isdn/i4l/isdn_concap.h - 1.2 linux/drivers/isdn/i4l/isdn_concap.c - 1.2 linux/drivers/isdn/i4l/isdn_common.h - 1.3 linux/drivers/isdn/i4l/isdn_common.c - 1.7 linux/fs/exportfs/expfs.c - 1.6 linux/drivers/isdn/i4l/Makefile - 1.4 linux/sound/pci/rme32.c - 1.4 linux/drivers/block/umem.c - 1.10 linux/drivers/net/wireless/orinoco_pci.c - 1.3 linux/drivers/pci/pool.c - 1.5 linux/include/linux/page-flags.h - 1.12 linux/kernel/suspend.c - 1.14 linux/drivers/usb/host/hc_sl811.c - 1.2 linux/drivers/usb/core/urb.c - 1.6 linux/drivers/usb/core/message.c - 1.7 linux/include/asm-s390x/qdio.h - 1.2 linux/drivers/usb/host/ohci-sa1111.c - 1.5 linux/include/asm-s390/qdio.h - 1.2 linux/drivers/s390/block/dasd_genhd.c - 1.8 linux/arch/i386/kernel/cpu/Makefile - 1.3 linux/include/net/llc_sap.h - 1.5 linux/net/llc/llc_sock.c - 1.6 linux/net/llc/llc_sap.c - 1.6 linux/net/llc/llc_s_ac.c - 1.5 linux/net/llc/llc_mac.c - 1.6 linux/include/net/llc_mac.h - 1.4 linux/net/llc/Makefile - 1.3 linux/net/llc/llc_main.c - 1.7 linux/net/llc/llc_conn.c - 1.6 linux/include/net/llc_conn.h - 1.5 linux/sound/pci/rme9652/multiface_firmware.dat - 1.2 linux/sound/pci/rme9652/hdsp.c - 1.2 linux/sound/pci/rme9652/digiface_firmware.dat - 1.2 linux/drivers/input/keyboard/sunkbd.c - 1.4 linux/fs/smbfs/smbiod.c - 1.3 linux/fs/smbfs/request.c - 1.2 linux/drivers/input/serio/sa1111ps2.c - 1.2 linux/include/asm-ppc64/mmzone.h - 1.6 linux/drivers/bluetooth/bt3c_cs.c - 1.2 linux/include/asm-i386/mmzone.h - 1.4 linux/include/asm-i386/numaq.h - 1.4 linux/drivers/ide/setup-pci.c - 1.5 linux/include/asm-um/tlbflush.h - 1.2 linux/include/asm-um/timex.h - 1.2 linux/include/asm-um/system-i386.h - 1.2 linux/drivers/ide/legacy/hd.c - 1.5 linux/arch/um/Makefile - 1.3 linux/arch/um/Makefile-os-Linux - 1.2 linux/arch/um/config.in - 1.2 linux/arch/um/defconfig - 1.2 linux/arch/um/drivers/ubd_kern.c - 1.2 linux/arch/um/include/mem_user.h - 1.2 linux/arch/um/include/user_util.h - 1.2 linux/arch/um/kernel/Makefile - 1.3 linux/arch/um/kernel/mem.c - 1.2 linux/arch/um/kernel/mem_user.c - 1.2 linux/arch/um/kernel/process_kern.c - 1.2 linux/arch/um/kernel/reboot.c - 1.2 linux/arch/um/kernel/sys_call_table.c - 1.2 linux/arch/um/kernel/tlb.c - 1.2 linux/arch/um/kernel/um_arch.c - 1.2 linux/arch/um/link.ld.in - 1.2 linux/include/asm-um/pgtable.h - 1.2 linux/include/asm-um/pgalloc.h - 1.2 linux/include/asm-um/percpu.h - 1.2 linux/include/asm-um/page.h - 1.2 linux/include/asm-um/irq.h - 1.2 linux/include/asm-um/highmem.h - 1.2 linux/drivers/char/drm/radeon_irq.c - 1.2 linux/drivers/base/hotplug.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:50:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:51:00 -0700 (PDT) Received: from motion.christooley.cjb.net (66-141-61-61.ded.swbell.net [66.141.61.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FoutG011675 for ; Wed, 2 Oct 2002 08:50:57 -0700 Received: (from ctooley@localhost) by motion.christooley.cjb.net (8.11.6/8.11.6) id g92Fore05158; Wed, 2 Oct 2002 10:50:53 -0500 X-Authentication-Warning: motion.christooley.cjb.net: ctooley set sender to ctooley@amoa.org using -f Subject: Re: Begging :^) From: Chris Tooley To: Seth Mos Cc: Simon Matter , Bill Anderson , "Linux XFS (SGI)" In-Reply-To: <20021002115719.C1780-100000@xs1.xs4all.nl> References: <20021002115719.C1780-100000@xs1.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Oct 2002 10:50:52 -0500 Message-Id: <1033573852.5070.6.camel@motion> Mime-Version: 1.0 X-archive-position: 704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs I saw this too, I was going to ask how we reopen it for them. :) Chris On Wed, 2002-10-02 at 04:58, Seth Mos wrote: > On Wed, 2 Oct 2002, Simon Matter wrote: > > > Bill Anderson schrieb: > > > > > > On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > > > > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > The bug is CLOSED and DEFERRED. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74170 > > > > I'm looking forward to 8.1 :) > > I think they really don't want to :-) > > Cheers > > From owner-linux-xfs@oss.sgi.com Wed Oct 2 08:58:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 08:58:55 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FwqtG012209 for ; Wed, 2 Oct 2002 08:58:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA49392; Wed, 2 Oct 2002 10:58:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA36447; Wed, 2 Oct 2002 10:58:46 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92FwOY10794; Wed, 2 Oct 2002 10:58:24 -0500 Subject: Re: Suggestions for kernel/XFS version? From: Steve Lord To: Theo Van Dinter Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021002154037.GD1527@kluge.net> References: <20021002154037.GD1527@kluge.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Oct 2002 10:58:24 -0500 Message-Id: <1033574304.6943.53.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Just a simple answer, those 'snapshots' that you see are probably a lot more stable than 1.1 or 1.0 were. Most of what has gone into xfs since 1.1 has been bug fixes and code cleanup. In general I run the cvs tree, plus other changes I am working on on my workstation. Unless I messed up somewhere in those extra changes, I have zero problems. We run nightly regression tests internally, and it is only rarely that they show anything up. Steve On Wed, 2002-10-02 at 10:40, Theo Van Dinter wrote: > I've been using XFS for a while, but find myself in a bit of a quandry > about where to go now... > > A week or two ago, my main server got very flaky (semi-constant > rebooting), so I replaced the Athlon UP MB/CPU for a nice > Athlon MP version. It came up fine with the kernel at the time > (2.4.9-31SGI_XFS_1.1, no data loss or errors), so I upgraded to > smp-2.4.18-4SGI_XFS_1.1 to get a recent MP-based kernel. > > The server has a 3ware RAID controller, and also uses LVM, so I've been > paying attention to versions of these drivers. 2.4.18 and previous > had old versions of the 3ware driver, so I would compile a new version > whenever I changed kernels. > > This is when I noticed that the UP XFS 2.4.18-4 (could have been > XFS 2.4.18 instead) kernel had LVM 1.0.3, whereas SMP XFS 2.4.18-4 > has 1.0.1-rc4. I also found that SMP XFS 2.4.18-4 seemed to hit the > disk a lot for writes, almost like it had no or only a very small > kernel-level write cache/XFS pre-allocation space. (write cache is off > on the controller) > > Since the performance was noticably bad because of this, I switched last > night to SMP 2.4.18-SGI_XFS_1.1. This seems to have solved my performance > problem, but I now I have 2 new problems. 1) I'm left with LVM 1.0.1-rc4, > and 2) I can't compile a new 3w-xxxx driver (the module compiles, but I get > "Undefined symbols" when I run the depmod to verify installation). > > So the quandry is: Where should I go from here? So far, > 2.4.18-SGI_XFS_1.1 seems to have solved the performance issue I was > seeing, but has old LVM and 3w-xxxxx drivers which I'd like to upgrade. > It looks like 2.4.19 has LVM 1.0.3 and the correct 3w-xxxx driver version > already. So I could compile up my own kernel, but the only XFS patch I > see for 2.4.19 is a CVS snapshot from last week. I'm leary of using a > snapshot for an integral part of the kernel, but there doesn't seem to > be a 1.1 patch for 2.4.19 (and the 2.4.18 patch seems to be XFS 1.1-PR2). > > Any thoughts? Thanks. :) > > -- > Randomly Generated Tagline: > "Now it's time for pay back ... Can someone lend me enough for a Coke?" > - Chris Bentley -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 2 09:05:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 09:05:14 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92G57tG012766 for ; Wed, 2 Oct 2002 09:05:08 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id B382FC012D1; Thu, 3 Oct 2002 00:04:47 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 43682C012D1; Thu, 3 Oct 2002 00:04:34 +0800 (PHT) Date: Thu, 3 Oct 2002 00:04:33 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Suggestions for kernel/XFS version? Message-ID: <20021002160433.GQ26027@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021002154037.GD1527@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021002154037.GD1527@kluge.net> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Scanned-By: AMaViS "Next Generation" using McAfee uvscan and ClamAV X-archive-position: 706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs On Wed, Oct 02, 2002 at 11:40:37AM -0400, Theo Van Dinter wrote: > So the quandry is: Where should I go from here? So far, > 2.4.18-SGI_XFS_1.1 seems to have solved the performance issue I was > seeing, but has old LVM and 3w-xxxxx drivers which I'd like to > upgrade. It looks like 2.4.19 has LVM 1.0.3 and the correct 3w-xxxx > driver version already. So I could compile up my own kernel, but the > only XFS patch I see for 2.4.19 is a CVS snapshot from last week. I'm > leary of using a snapshot for an integral part of the kernel, but > there doesn't seem to be a 1.1 patch for 2.4.19 (and the 2.4.18 patch > seems to be XFS 1.1-PR2). As a constant follower of the XFS CVS tree -- and a fellow user of a 3ware card (although I have never used LVM) -- I have found that the XFS CVS tree is very acceptably stable. The SGI team does a pretty good job of testing changes before committing them into CVS. Admittedly CVS snapshots do not have the kind of stability blessing that releases get, but you might be better off with an unpatched CVS snapshot than with a kernel built with a combination of hand-patches that may not be as widely tested. Plus of course you get the benefit of being an early beneficiary of the code cleanups and minor bugfixes and optimizations that the SGI team puts in. Indeed these are not as "rock solid tested" as the release kernels, but I believe they're well tested enough. If you need that "stability guarantee" you probably want to stick with a released kernel, otherwise the CVS seems to be pretty good. --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Wed Oct 2 10:04:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 10:04:32 -0700 (PDT) Received: from fs1.theiqgroup.com (fs1.theiqgroup.com [216.81.249.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92H4TtG014307 for ; Wed, 2 Oct 2002 10:04:29 -0700 Received: from theiqgroup.com (funkmotor.funkmotor.org [216.81.249.31]) by fs1.theiqgroup.com (8.12.4/8.12.2) with ESMTP id g92H4NOH032104; Wed, 2 Oct 2002 12:04:23 -0500 Message-ID: <3D9B2717.8000905@theiqgroup.com> Date: Wed, 02 Oct 2002 12:04:23 -0500 From: Kelly Corbin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: Suggestions for kernel/XFS version? Release? References: <20021002154037.GD1527@kluge.net> <1033574304.6943.53.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kcorbin@theiqgroup.com Precedence: bulk X-list: linux-xfs I know you guys get asked this alot, but what's your best guesstimate of your next full release? I'm not having any problems with my current XFS installations, so I'm wondering if I should just wait a little while longer to upgrade from 2.4.16 (XFS 1.1) to 2.4.19 (next XFS release), or go ahead an do it now (XFS from CVS) because a release is not in the near future. Thanks! Kelly Steve Lord wrote: > Just a simple answer, those 'snapshots' that you see are probably a lot > more stable than 1.1 or 1.0 were. Most of what has gone into xfs since > 1.1 has been bug fixes and code cleanup. In general I run the cvs tree, > plus other changes I am working on on my workstation. Unless I messed > up somewhere in those extra changes, I have zero problems. We run > nightly regression tests internally, and it is only rarely that > they show anything up. > > Steve > > On Wed, 2002-10-02 at 10:40, Theo Van Dinter wrote: > >>I've been using XFS for a while, but find myself in a bit of a quandry >>about where to go now... >> >>A week or two ago, my main server got very flaky (semi-constant >>rebooting), so I replaced the Athlon UP MB/CPU for a nice >>Athlon MP version. It came up fine with the kernel at the time >>(2.4.9-31SGI_XFS_1.1, no data loss or errors), so I upgraded to >>smp-2.4.18-4SGI_XFS_1.1 to get a recent MP-based kernel. >> >>The server has a 3ware RAID controller, and also uses LVM, so I've been >>paying attention to versions of these drivers. 2.4.18 and previous >>had old versions of the 3ware driver, so I would compile a new version >>whenever I changed kernels. >> >>This is when I noticed that the UP XFS 2.4.18-4 (could have been >>XFS 2.4.18 instead) kernel had LVM 1.0.3, whereas SMP XFS 2.4.18-4 >>has 1.0.1-rc4. I also found that SMP XFS 2.4.18-4 seemed to hit the >>disk a lot for writes, almost like it had no or only a very small >>kernel-level write cache/XFS pre-allocation space. (write cache is off >>on the controller) >> >>Since the performance was noticably bad because of this, I switched last >>night to SMP 2.4.18-SGI_XFS_1.1. This seems to have solved my performance >>problem, but I now I have 2 new problems. 1) I'm left with LVM 1.0.1-rc4, >>and 2) I can't compile a new 3w-xxxx driver (the module compiles, but I get >>"Undefined symbols" when I run the depmod to verify installation). >> >>So the quandry is: Where should I go from here? So far, >>2.4.18-SGI_XFS_1.1 seems to have solved the performance issue I was >>seeing, but has old LVM and 3w-xxxxx drivers which I'd like to upgrade. >>It looks like 2.4.19 has LVM 1.0.3 and the correct 3w-xxxx driver version >>already. So I could compile up my own kernel, but the only XFS patch I >>see for 2.4.19 is a CVS snapshot from last week. I'm leary of using a >>snapshot for an integral part of the kernel, but there doesn't seem to >>be a 1.1 patch for 2.4.19 (and the 2.4.18 patch seems to be XFS 1.1-PR2). >> >>Any thoughts? Thanks. :) >> >>-- >>Randomly Generated Tagline: >>"Now it's time for pay back ... Can someone lend me enough for a Coke?" >> - Chris Bentley > -- -------------------------------------------- -- Kelly Corbin -- Systems Administrator -- -- http://www.theiqgroup.com -- The Future of eServices... -- -- The IQ Group, Inc. -- 6740 Antioch Suite 110 -- Merriam, KS 66204 -- (913)-722-6700 x105 -- Fax (913)722-7264 -------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Oct 2 10:26:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 10:26:46 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92HQitG014918 for ; Wed, 2 Oct 2002 10:26:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA86024 for ; Wed, 2 Oct 2002 12:26:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA26992 for ; Wed, 2 Oct 2002 12:26:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92HQFh02354; Wed, 2 Oct 2002 12:26:15 -0500 Message-Id: <200210021726.g92HQFh02354@jen.americas.sgi.com> Date: Wed, 2 Oct 2002 12:26:15 -0500 Subject: TAKE - code cleanup To: linux-xfs@oss.sgi.com X-archive-position: 708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs This is a two fold change, first it moves the translation between linux dev_t and kdev_t up the call stack in xfs and makes the bulk of xfs work in terms of its on disk dev_t format. It also cleans up a few related chunks of code. The other part of the change reworks how we keep the linux inode contents and the xfs inode fields in sync. A number of places where we resynced the two have been removed, these were basically replicating work elsewhere in the filesystem. We now also ensure that the inode fields are filled in before calling unlock_new_inode - there used to be a window. Finally all the code which hooks together the linux inode and the xfs inode is brought together as a more coherent whole rather than being scattered around the inode create path. Most calls to revalidate the linux inode from the xfs inode are removed. Date: Wed Oct 2 10:25:30 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128899a linux/fs/xfs/xfs_vnodeops.c - 1.566 - At this level all the code now speaks in terms of xfs dev_t format. linux/fs/xfs/xfs_dmapi.c - 1.79 - Change IRIX_DEV_TO_KDEV_T to XFS_DEV_TO_KDEV_T linux/fs/xfs/xfs_vfsops.c - 1.387 - Add in the vnode initialization operation. linux/fs/xfs/xfs_iget.c - 1.174 - Introduce xfs_revalidate_inode, this is a function to translate internal xfs format inode fields into the linux inode format. Move all vnode and inode linkage, and setup of the linux inode into the VFS_INIT_INODE() call. linux/fs/xfs/xfs_qm.c - 1.84 - No need to feed in a dev_t here, we are creating a regular file and we ignore the rdev field. linux/fs/xfs/xfs_inode.c - 1.350 - Change to an xfs format dev_t at this level, call the new VFS_INIT_INODE() function rather than just the set inode ops call. linux/fs/xfs/xfs_inode.h - 1.169 - Prototype changes for dev_t format linux/fs/xfs/xfs_types.h - 1.61 - Change xfs dev_t manipulation macros to be XFS_ from IRIX_ linux/fs/xfs/xfs_utils.c - 1.53 - Change xfs_dir_ialloc to take an xfs format dev_t linux/fs/xfs/xfs_utils.h - 1.27 - Change prototype for xfs_dir_ialloc linux/fs/xfs/linux/xfs_vnode.c - 1.98 - In vn_revalidate, account for the format change in va_rdev also remove the flags argument, and simplify the code linux/fs/xfs/linux/xfs_super.c - 1.216 - remove a linvfs_revalidate_core call, remove the inode state checks and unlock_new_inode call from the linvfs_set_inode_ops function. linux/fs/xfs/linux/xfs_iops.c - 1.175 - remove linvfs_revalidate_core and calls to it, pass va_rdev around in xfs format rather than kernel format. linux/fs/xfs/linux/xfs_iops.h - 1.17 - Remove linvfs_revalidate_core linux/fs/xfs/linux/xfs_ioctl.c - 1.77 - Remove a linvfs_revalidate call linux/fs/xfs/linux/xfs_vnode.h - 1.65 - Change the vattr_t structure to contain dev_t's in xfs format rather than as kdev_t structures. Change prototype for vn_revalidate. linux/fs/xfs/linux/xfs_vfs.h - 1.30 - Add a new vfs operation - INIT_INODE. This is used by the filesystem to glue the xfs inode, the vnode and the linux inode together. From owner-linux-xfs@oss.sgi.com Wed Oct 2 11:39:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 11:39:42 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92IdbtG016324 for ; Wed, 2 Oct 2002 11:39:37 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA62277; Wed, 2 Oct 2002 13:39:31 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA19196; Wed, 2 Oct 2002 13:39:31 -0500 (CDT) Subject: Re: Suggestions for kernel/XFS version? Release? From: Eric Sandeen To: Kelly Corbin Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <3D9B2717.8000905@theiqgroup.com> References: <20021002154037.GD1527@kluge.net> <1033574304.6943.53.camel@jen.americas.sgi.com> <3D9B2717.8000905@theiqgroup.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 02 Oct 2002 13:38:16 -0500 Message-Id: <1033583896.28489.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs We're working on it now, hopefully a prerelease/test release will be available fairly soon. -Eric On Wed, 2002-10-02 at 12:04, Kelly Corbin wrote: > I know you guys get asked this alot, but what's your best guesstimate of > your next full release? I'm not having any problems with my current XFS > installations, so I'm wondering if I should just wait a little while > longer to upgrade from 2.4.16 (XFS 1.1) to 2.4.19 (next XFS release), or > go ahead an do it now (XFS from CVS) because a release is not in the > near future. > > Thanks! > > Kelly -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Oct 2 11:47:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 11:47:46 -0700 (PDT) Received: from alucicrazy.tacnet.com.br (200.152.199.163.metrored.net.br [200.152.199.163] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92IlRtG016835 for ; Wed, 2 Oct 2002 11:47:38 -0700 Received: by alucicrazy.tacnet.com.br (Postfix, from userid 1015) id 8BBC51C71EB5; Wed, 2 Oct 2002 15:47:16 -0300 (BRT) Date: Wed, 2 Oct 2002 15:47:16 -0300 To: linux-xfs@oss.sgi.com Subject: Xfs file recovery Message-ID: <20021002184716.GA2127@alucicrazy.tacnet.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: hal@alucicrazy.tacnet.com.br (bueno) X-archive-position: 710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hal@alucicrazy.tacnet.com.br Precedence: bulk X-list: linux-xfs Hi, I have deleted some file from a xfs partition I immediately run xfs_freeze on device And createa a "dd" of device... Editing in a hexa editor, I saw the data that had been deleted on dd file... Exists a form to recovery these data ? Thanks Ps - sorry the english... -- ^hal http://hal.vu From owner-linux-xfs@oss.sgi.com Wed Oct 2 11:55:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 11:55:27 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92ItNtG017337 for ; Wed, 2 Oct 2002 11:55:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA86866 for ; Wed, 2 Oct 2002 13:55:17 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA81966 for ; Wed, 2 Oct 2002 13:55:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g92Is2B07457; Wed, 2 Oct 2002 13:54:02 -0500 Message-Id: <200210021854.g92Is2B07457@stout.americas.sgi.com> Date: Wed, 2 Oct 2002 13:54:02 -0500 Subject: TAKE - add a couple make targets to xfs-cmds. X-archive-position: 711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This is for an internal build system, but at least now maybe we can change the default make target away from building RPMs... Add a couple targets for LBS. Date: Wed Oct 2 11:51:54 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:128903a Makefile - 1.5 - Add a couple targets for LBS. From owner-linux-xfs@oss.sgi.com Wed Oct 2 12:39:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 12:39:31 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92JdStG019445 for ; Wed, 2 Oct 2002 12:39:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA55566 for ; Wed, 2 Oct 2002 14:39:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA01784 for ; Wed, 2 Oct 2002 14:39:22 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g92Jc7R08340; Wed, 2 Oct 2002 14:38:07 -0500 Message-Id: <200210021938.g92Jc7R08340@stout.americas.sgi.com> Date: Wed, 2 Oct 2002 14:38:07 -0500 Subject: TAKE - Allow quota inode creation on a read-only filesystem. X-archive-position: 712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This is a step in the direction of removing special handling of the rootdev vs. quotas. This will allow quota inode creation on a read-only filesystem, which would happen if you want to pass in "quota" as a rootdev option via lilo, and you have not had quotas before. The filesystem will temporarily be read-write while the inodes are created, like we currently do for quotacheck and recovery. Nothing in this change should affect the way quota currently works, it just adds the option of turning them on for the first time on a read-only fs. Allow quota inode creation on a read-only filesystem. Date: Wed Oct 2 12:22:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128905a linux/fs/xfs/xfs_qm.c - 1.85 - use xfs_quotaino_create_read_only() and switch temporarily to read-write so that we can create quota inodes, if necessary. (Similar to recovery & quotachk on an ro fs.) linux/fs/xfs/linux/xfs_lrw.h - 1.26 linux/fs/xfs/linux/xfs_lrw.c - 1.168 - Add xfs_quotaino_create_read_only() From owner-linux-xfs@oss.sgi.com Wed Oct 2 12:59:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 12:59:32 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92JxUtG020020 for ; Wed, 2 Oct 2002 12:59:30 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 MAA04798 for ; Wed, 2 Oct 2002 12:59:28 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g92JwNK4009670 for ; Wed, 2 Oct 2002 21:58:23 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g92JwM1A009669 for linux-xfs@oss.sgi.com; Wed, 2 Oct 2002 21:58:22 +0200 Date: Wed, 2 Oct 2002 21:58:22 +0200 Message-Id: <200210021958.g92JwM1A009669@lab343.munich.sgi.com> Subject: TAKE - One more place where we should use d_alloc_anon To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs This one wasn't converted in early 2.5 when the others were. Don't ask me why.. Date: Wed Oct 2 12:58:14 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128909a linux/fs/xfs/dmapi/dmapi_register.c - 1.19 - Use d_alloc_anon in dm_open_by_handle_rvp instead of open-coding. From owner-linux-xfs@oss.sgi.com Wed Oct 2 13:04:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 13:04:04 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92K41tG020608 for ; Wed, 2 Oct 2002 13:04:01 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 NAA06282 for ; Wed, 2 Oct 2002 13:04:00 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g92K3FK4010052 for ; Wed, 2 Oct 2002 22:03:15 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g92K3FlN010051 for linux-xfs@oss.sgi.com; Wed, 2 Oct 2002 22:03:15 +0200 Date: Wed, 2 Oct 2002 22:03:15 +0200 Message-Id: <200210022003.g92K3FlN010051@lab343.munich.sgi.com> Subject: TAKE - Remove dead variable. To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Oct 2 13:03:26 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128913a linux/fs/xfs/linux/xfs_super.c - 1.230 - Remove dead variable in linvfs_put_super. From owner-linux-xfs@oss.sgi.com Wed Oct 2 13:09:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 13:09:11 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92K98tG021201 for ; Wed, 2 Oct 2002 13:09:08 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 NAA01649 for ; Wed, 2 Oct 2002 13:09:07 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g92K8MK4010276 for ; Wed, 2 Oct 2002 22:08:22 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g92K8M9h010275 for linux-xfs@oss.sgi.com; Wed, 2 Oct 2002 22:08:22 +0200 Date: Wed, 2 Oct 2002 22:08:22 +0200 Message-Id: <200210022008.g92K8M9h010275@lab343.munich.sgi.com> Subject: TAKE - Use mk_kdev to generate a kdev_t To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Oct 2 13:08:42 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:128915a linux/fs/xfs/dmapi/dmapi_sysent.c - 1.17 - Use mk_kdev to generate the kdev_t passed to proc_mkdir From owner-linux-xfs@oss.sgi.com Wed Oct 2 13:16:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 13:16:41 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92KGWtG021740 for ; Wed, 2 Oct 2002 13:16:33 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA91022 for ; Wed, 2 Oct 2002 15:16:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA23222 for ; Wed, 2 Oct 2002 15:16:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g92KG4Y11088; Wed, 2 Oct 2002 15:16:04 -0500 Message-Id: <200210022016.g92KG4Y11088@jen.americas.sgi.com> Date: Wed, 2 Oct 2002 15:16:04 -0500 Subject: TAKE - remove 'temporary debugging code' To: linux-xfs@oss.sgi.com X-archive-position: 716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs remove some 'temporary debugging code' which has been there a couple of years at least. Date: Wed Oct 2 13:15:57 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128918a linux/fs/xfs/xfs_bmap.c - 1.292 - remove extra checks in extent code which were always executed. From owner-linux-xfs@oss.sgi.com Wed Oct 2 14:39:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 14:39:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92LdktG024441 for ; Wed, 2 Oct 2002 14:39:47 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA89079; Wed, 2 Oct 2002 16:39:39 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA13329; Wed, 2 Oct 2002 16:39:39 -0500 (CDT) Subject: Re: the shell will make the xfs fs locked From: Eric Sandeen To: tom wang Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021001092416.74643.qmail@web15204.mail.bjs.yahoo.com> References: <20021001092416.74643.qmail@web15204.mail.bjs.yahoo.com> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 02 Oct 2002 16:38:23 -0500 Message-Id: <1033594703.1874.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g92LdmtG024442 X-archive-position: 717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs We're looking at the problem here, and we can duplicate it. It will be a hard problem to solve, but the main problem is that you are creating so many extents in the file. If you do not create so many extents, you will not have this problem. -Eric On Tue, 2002-10-01 at 04:24, tom wang wrote: > xfs-developers: > when I run the shell program as following on a xfs > FS, the process will locked. > > #!/bin/sh > for((i=0;i<300000;i++)); do > truncate /mnt/current/a $(($i*8192)); > cat /tmp/4kfile >> /mnt/current/a > done > /tmp/4kfile is a 4096-sized file > xfs FS mounted at /mnt/current > the truncate program: > > #include > #include > #include > > int main(int argc, char *argv[]) > { > long long length = 0; > > if( argc < 2 || argc > 3 ){ > printf("Usage: truncate filename [length]\n"); > return -1; > } > > if( argv[2] ) > length = atoll(argv[2]); > > if( truncate64( argv[1], length ) ){ > perror("truncate failed"); > return -1; > } > return 0; > } > > > _________________________________________________________ > Do You Yahoo!? > "鍙戠煭淇¤耽鎵嬫満,蹇潵鍙傚姞闆呰檸宸ㄦ槦绉!" > http://cn.ent.yahoo.com/star/midautumn/index.html > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Oct 2 14:53:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 14:53:30 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92LrRtG024986 for ; Wed, 2 Oct 2002 14:53:27 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA88919; Wed, 2 Oct 2002 16:53:20 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA44058; Wed, 2 Oct 2002 16:53:20 -0500 (CDT) Subject: Re: Xfs file recovery From: Eric Sandeen To: bueno Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021002184716.GA2127@alucicrazy.tacnet.com.br> References: <20021002184716.GA2127@alucicrazy.tacnet.com.br> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 02 Oct 2002 16:52:03 -0500 Message-Id: <1033595524.28489.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs There is no simple way to recover deleted xfs files, I am afraid. http://oss.sgi.com/projects/xfs/faq.html#undelete If these were text files that were deleted, and they were not very fragmented, and you might be able to use dd to extract them when you find them. In general though data recovery is expensive because it's tricky and not something that can be explained in a short email, if it is even possible. -Eric On Wed, 2002-10-02 at 13:47, bueno wrote: > Hi, > I have deleted some file from a xfs partition > I immediately run xfs_freeze on device > And createa a "dd" of device... > Editing in a hexa editor, I saw the data that had been deleted > on dd file... > Exists a form to recovery these data ? > Thanks > Ps - sorry the english... > > -- > ^hal > > http://hal.vu > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Oct 2 18:27:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 18:27:50 -0700 (PDT) Received: from web15212.mail.bjs.yahoo.com ([61.135.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g931RgtG001813 for ; Wed, 2 Oct 2002 18:27:44 -0700 Message-ID: <20021003012732.63796.qmail@web15212.mail.bjs.yahoo.com> Received: from [210.196.157.115] by web15212.mail.bjs.yahoo.com via HTTP; Thu, 03 Oct 2002 09:27:32 CST Date: Thu, 3 Oct 2002 09:27:32 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: Re: the shell will make the xfs fs locked To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033594703.1874.11.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs Hope you will be soon fix this problem. because we are now testing xfs filesystem and decide wether use xfs as the file server in our product. thanks. --- Eric Sandeen 的正文：> We're looking at the problem here, and we can > duplicate it. > > It will be a hard problem to solve, but the main > problem is that you are > creating so many extents in the file. If you do not > create so many > extents, you will not have this problem. > > -Eric > > On Tue, 2002-10-01 at 04:24, tom wang wrote: > > xfs-developers: > > when I run the shell program as following on a > xfs > > FS, the process will locked. > > > > #!/bin/sh > > for((i=0;i<300000;i++)); do > > truncate /mnt/current/a $(($i*8192)); > > cat /tmp/4kfile >> /mnt/current/a > > done > > /tmp/4kfile is a 4096-sized file > > xfs FS mounted at /mnt/current > > the truncate program: > > > > #include > > #include > > #include > > > > int main(int argc, char *argv[]) > > { > > long long length = 0; > > > > if( argc < 2 || argc > 3 ){ > > printf("Usage: truncate filename [length]\n"); > > return -1; > > } > > > > if( argv[2] ) > > length = atoll(argv[2]); > > > > if( truncate64( argv[1], length ) ){ > > perror("truncate failed"); > > return -1; > > } > > return 0; > > } > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > "鍙戠煭淇¤耽鎵嬫満,蹇潵鍙傚姞闆呰檸宸ㄦ槦绉€!" > > http://cn.ent.yahoo.com/star/midautumn/index.html > > > -- > Eric Sandeen XFS for Linux > http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html From owner-linux-xfs@oss.sgi.com Wed Oct 2 18:42:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 18:42:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g931grtG002345 for ; Wed, 2 Oct 2002 18:42:53 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA95416; Wed, 2 Oct 2002 20:42:45 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-34.corp.sgi.com [134.15.64.34]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA42188; Wed, 2 Oct 2002 20:42:45 -0500 (CDT) Subject: Re: the shell will make the xfs fs locked From: Stephen Lord To: tom wang Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20021003012732.63796.qmail@web15212.mail.bjs.yahoo.com> References: <20021003012732.63796.qmail@web15212.mail.bjs.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 02 Oct 2002 20:40:40 -0500 Message-Id: <1033609242.1051.7.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g931grtG002346 X-archive-position: 720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-10-02 at 20:27, tom wang wrote: > > > Hope you will be soon fix this problem. > because we are now testing xfs filesystem and > decide wether use xfs as the file server in our > product. The particular scenario you are testing created 64K extents in a file before it died here. What you are doing here does not bear a lot of resemblance to any reasonable application I can think of. As Eric said, this is not a simple thing to fix, and probably not something which will get fixed completely for a while. Steve > > thanks. > > --- Eric Sandeen 的正文：> We're > looking at the problem here, and we can > > duplicate it. > > > > It will be a hard problem to solve, but the main > > problem is that you are > > creating so many extents in the file. If you do not > > create so many > > extents, you will not have this problem. > > > > -Eric > > > > On Tue, 2002-10-01 at 04:24, tom wang wrote: > > > xfs-developers: > > > when I run the shell program as following on a > > xfs > > > FS, the process will locked. > > > > > > #!/bin/sh > > > for((i=0;i<300000;i++)); do > > > truncate /mnt/current/a $(($i*8192)); > > > cat /tmp/4kfile >> /mnt/current/a > > > done > > > /tmp/4kfile is a 4096-sized file > > > xfs FS mounted at /mnt/current > > > the truncate program: > > > > > > #include > > > #include > > > #include > > > > > > int main(int argc, char *argv[]) > > > { > > > long long length = 0; > > > > > > if( argc < 2 || argc > 3 ){ > > > printf("Usage: truncate filename [length]\n"); > > > return -1; > > > } > > > > > > if( argv[2] ) > > > length = atoll(argv[2]); > > > > > > if( truncate64( argv[1], length ) ){ > > > perror("truncate failed"); > > > return -1; > > > } > > > return 0; > > > } > > > > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > > "鍙戠煭淇¤耽鎵嬫満,蹇潵鍙傚 闆呰檸宸ㄦ槦绉€!" > > > http://cn.ent.yahoo.com/star/midautumn/index.html > > > > > -- > > Eric Sandeen XFS for Linux > > http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. 651-683-3102 > > > > _________________________________________________________ > Do You Yahoo!? > "发短信赢手机,快来参加雅虎巨星秀!" > http://cn.ent.yahoo.com/star/midautumn/index.html > From owner-linux-xfs@oss.sgi.com Wed Oct 2 18:50:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 18:50:06 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g931o3tG002895 for ; Wed, 2 Oct 2002 18:50:04 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8CD6914B56; Thu, 3 Oct 2002 03:49:58 +0200 (MEST) Date: Thu, 3 Oct 2002 03:49:57 +0200 From: Andi Kleen To: Stephen Lord Cc: tom wang , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: the shell will make the xfs fs locked Message-ID: <20021003034957.A2455@wotan.suse.de> References: <20021003012732.63796.qmail@web15212.mail.bjs.yahoo.com> <1033609242.1051.7.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033609242.1051.7.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Wed, Oct 02, 2002 at 08:40:40PM -0500, Steve Lord wrote: > On Wed, 2002-10-02 at 20:27, tom wang wrote: > > > > > > Hope you will be soon fix this problem. > > because we are now testing xfs filesystem and > > decide wether use xfs as the file server in our > > product. > > The particular scenario you are testing created 64K > extents in a file before it died here. What you are > doing here does not bear a lot of resemblance to > any reasonable application I can think of. > > As Eric said, this is not a simple thing to fix, and > probably not something which will get fixed completely > for a while. It still looks like a kind of security/DoS problem. Is there a simple way to check for the condition and -EINVAL or EIO in this case at least ? -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 2 19:04:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 19:04:51 -0700 (PDT) Received: from web15210.mail.bjs.yahoo.com ([61.135.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9324jtG007817 for ; Wed, 2 Oct 2002 19:04:47 -0700 Message-ID: <20021003020438.5114.qmail@web15210.mail.bjs.yahoo.com> Received: from [210.196.157.115] by web15210.mail.bjs.yahoo.com via HTTP; Thu, 03 Oct 2002 10:04:38 CST Date: Thu, 3 Oct 2002 10:04:38 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: Re: the shell will make the xfs fs locked To: linux-xfs@oss.sgi.com In-Reply-To: <20021003034957.A2455@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs --- Andi Kleen 的正文：> On Wed, Oct 02, 2002 at 08:40:40PM -0500, Steve Lord > wrote: > > On Wed, 2002-10-02 at 20:27, tom wang wrote: > > > > > > > > > Hope you will be soon fix this problem. > > > because we are now testing xfs filesystem and > > > decide wether use xfs as the file server in our > > > product. > > > > The particular scenario you are testing created > 64K > > extents in a file before it died here. What you > are > > doing here does not bear a lot of resemblance to > > any reasonable application I can think of. > > > > As Eric said, this is not a simple thing to fix, > and > > probably not something which will get fixed > completely > > for a while. > > It still looks like a kind of security/DoS problem. > Is there a simple > way to check for the condition and -EINVAL or EIO in > this case at least ? > > -Andi > yeah. error messages and error handlers will be better than lock. thank for your response.xfs is really an excellent file system. _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html From owner-linux-xfs@oss.sgi.com Wed Oct 2 19:29:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 19:29:30 -0700 (PDT) Received: from alucicrazy.tacnet.com.br (200.152.199.163.metrored.net.br [200.152.199.163] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g932TPtG011008 for ; Wed, 2 Oct 2002 19:29:26 -0700 Received: by alucicrazy.tacnet.com.br (Postfix, from userid 1015) id D6CBF1C71EB5; Wed, 2 Oct 2002 23:29:23 -0300 (BRT) Date: Wed, 2 Oct 2002 23:29:23 -0300 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs file recovery Message-ID: <20021003022923.GE8296@alucicrazy.tacnet.com.br> References: <20021002184716.GA2127@alucicrazy.tacnet.com.br> <1033595524.28489.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033595524.28489.24.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i From: hal@alucicrazy.tacnet.com.br (bueno) X-archive-position: 723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hal@alucicrazy.tacnet.com.br Precedence: bulk X-list: linux-xfs Ok, Eric, Thanks for your help... I have run the commands: dd if=/dev/sdb3 of=/var/sdb3 chmod -r /var/sdb3 (hehe) srtrings /var/sdb3 >> /tmp/sdb3.str vi sdb3.str (1.1GB) Bye and thanks again... On Wed, Oct 02, 2002 at 04:52:03PM -0500, Eric Sandeen wrote: > There is no simple way to recover deleted xfs files, I am afraid. > > http://oss.sgi.com/projects/xfs/faq.html#undelete > > If these were text files that were deleted, and they were not very > fragmented, and you might be able to use dd to extract them when you > find them. > > In general though data recovery is expensive because it's tricky and not > something that can be explained in a short email, if it is even > possible. > > -Eric > > On Wed, 2002-10-02 at 13:47, bueno wrote: > > Hi, > > I have deleted some file from a xfs partition > > I immediately run xfs_freeze on device > > And createa a "dd" of device... > > Editing in a hexa editor, I saw the data that had been deleted > > on dd file... > > Exists a form to recovery these data ? > > Thanks > > Ps - sorry the english... > > > > -- > > ^hal > > > > http://hal.vu > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > -- ^hal http://hal.vu From owner-linux-xfs@oss.sgi.com Wed Oct 2 21:10:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 21:10:40 -0700 (PDT) Received: from intro.peace.co.nz (ftp.peace.co.nz [202.14.141.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g934AatG018954 for ; Wed, 2 Oct 2002 21:10:37 -0700 Received: from bongo ([10.0.2.9]) by intro.peace.co.nz (8.9.3/8.9.3) with ESMTP id QAA24726 for ; Thu, 3 Oct 2002 16:10:27 +1200 From: "James Braid" To: Subject: RE: AIO and XFS? Date: Thu, 3 Oct 2002 16:10:28 +1200 Message-ID: <018601c26a92$ceac8f20$0902000a@corp.peace.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20021002132651.A2141@infradead.org> X-archive-position: 724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james.braid@peace.com Precedence: bulk X-list: linux-xfs > > Or even better, has anyone got AIO and XFS working already? > > Of course it's possible. But it's not trivial. I'd suggest you wait > for aio getting fully implemented in 2.5, you can be sure > we'll adds supporti > for XFS there as soon as possible. > I think I kinda have XFS and AIO working now on 2.4.20pre8aa2, it is failing on one test case, 5.t, which says that it does "- Write from a mmap() of the same file. (5.t)". All I have done so far is add the following 4 lines into fs/xfs/linux/xfs_file.c: .kvec_read = generic_file_kvec_read, .kvec_write = generic_file_kvec_write, .aio_read = generic_file_aio_read, .aio_write = generic_file_aio_write, In the file_operations struct after the fsync entry in there. Anybody got any ideas why it would be failing on that specific test case? From owner-linux-xfs@oss.sgi.com Wed Oct 2 22:16:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 22:16:32 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g935GPtG020183 for ; Wed, 2 Oct 2002 22:16:26 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id TAA08996 for linux-xfs@oss.sgi.com; Wed, 2 Oct 2002 19:16:23 -1000 Date: Wed, 2 Oct 2002 19:16:23 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: kdb help, log recovery problems Message-ID: <20021002191623.A8961@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - We still have this filesystem which we created with 2.4.16 that seems to be unusable under 2.4.19. Newer kernels crash during log recovery whenever we attempt to mount. I just tried today's CVS kernel and kdb over the serial port as suggested, but I'm confused by the backtrace. I read about how kdb sometimes displays too many arguments, but some of the valid arguments don't make sense. For example, xlog_do_recovery_pass() seems to be given either a 0 or a 1 for the "pass" argument, but the argument in that position has the value from the previous stack level. Am I not using kdb properly? I've put a more complete minicom dump at this URL: http://software.cfht.hawaii.edu/minicom.cap Oh, and I'm using egcs-2.91.66, and frame pointers are turned on. Thanks for any advice you may have, - Sidik Stack traceback for pid 803 EBP EIP Function (args) 0xf770bf14 0xc0200613 xlog_recover_add_to_trans+0xb3 (0xf770bf14, 0xf6af0074, 0x60, 0x0, 0xf6b59bac) kernel .text 0xc0100000 0xc0200560 0xc02006dc 0xf6b59ae8 0xc0202227 xlog_recover_process_data+0x213 (0xf7cbfed4, 0xf6b59bac, 0xf7715a00, 0xf6af0074, 0x1) kernel .text 0xc0100000 0xc0202014 0xc0202290 0xc03ccd00 (msstab+0x44ae) 0xc01094ce (nmi+0x1e) 0xc0541220 (async_sercons) 0xc0541220 (async_sercons) 0xf6b59bec 0xc02030ee xlog_do_recovery_pass+0x3e6 (0xf7cbfed4, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc0202d08 0xc0203898 0xf6b59c20 0xc02038cb xlog_do_log_recovery+0x33 (0xf7cbfed4, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc0203898 0xc0203960 0xf6b59c50 0xc0203982 xlog_do_recover+0x22 (0xf7cbfed4, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc0203960 0xc0203b18 0xc038dc40 (extflag.748+0x3878) 0xf6b59ca4 0xc0203bac xlog_recover+0x94 (0xf7cbfed4, 0x1, 0xf786ec00, 0x40000, 0x5f800080) kernel .text 0xc0100000 0xc0203b18 0xc0203bd8 0xf6b59cc4 0xc01f9907 xfs_log_mount+0xc7 (0xf786ec00, 0x900, 0x5f800080, 0x0, 0x40000) kernel .text 0xc0100000 0xc01f9840 0xc01f993c 0xc04c6000 (init_task_union) From owner-linux-xfs@oss.sgi.com Wed Oct 2 23:10:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Oct 2002 23:10:27 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g936ALtG021119 for ; Wed, 2 Oct 2002 23:10:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 XAA08628 for ; Wed, 2 Oct 2002 23:10:20 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27580; Thu, 3 Oct 2002 16:09:02 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0ABA73001F4; Thu, 3 Oct 2002 16:09:01 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id F07251093; Thu, 3 Oct 2002 16:09:01 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Sidik Isani Cc: linux-xfs@sgi.com Subject: Re: kdb help, log recovery problems In-reply-to: Your message of "Wed, 02 Oct 2002 19:16:23 -1000." <20021002191623.A8961@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Oct 2002 16:08:56 +1000 Message-ID: <4084.1033625336@kao2.melbourne.sgi.com> X-archive-position: 726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2 Oct 2002 19:16:23 -1000, Sidik Isani wrote: > confused by the backtrace. I read about how kdb sometimes displays > too many arguments, but some of the valid arguments don't make > sense. For example, xlog_do_recovery_pass() seems to be given > either a 0 or a 1 for the "pass" argument, but the argument in > that position has the value from the previous stack level. Am > I not using kdb properly? I've put a more complete minicom dump > at this URL: http://software.cfht.hawaii.edu/minicom.cap >0xf6b59bec 0xc02030ee xlog_do_recovery_pass+0x3e6 (0xf7cbfed4, 0x36c58, 0x0, 0x36220, 0x0) > kernel .text 0xc0100000 0xc0202d08 0xc0203898 xlog_do_recovery_pass(xlog_t *log, xfs_daddr_t head_blk, xfs_daddr_t tail_blk, int pass) head_blk and tail_blk are defined as xfs_daddr_t, 64 bit values (long long on i386) which occupy two words on stack, with the most significant word coming second. kdb has no idea about the parameter types, the backtrace prints _words_. That trace shows :- log = 0xf7cbfed4 head_blk = [0,0x36c58] tail_blk = [0,0x36220] The default for kdb is to stop after 5 words of parameters, pass is not being printed. At the kdb prompt 'set BTARGS 6' then backtrace. From owner-linux-xfs@oss.sgi.com Thu Oct 3 02:29:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 02:29:10 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g939T4tG007468 for ; Thu, 3 Oct 2002 02:29:05 -0700 Received: (qmail 12704 invoked by uid 1000); 3 Oct 2002 09:44:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Oct 2002 09:44:05 -0000 Date: Thu, 3 Oct 2002 12:44:05 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: hints Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi We have used XFS on productions systems with great success. We will soon enter a process of hardware upgrades. One of the servers was experiencing a strange problem. By reading this list we concluded to be related to the "default" small XFS log size on "larger" filesystems. I know I may be wrong and the tests I will do before the upgrades will prove this to me. This is what I thought to do , to optimize I/O for the future systems. I will test with bonnie++ and other I/O benchmark tools different configurations: - different XFS log sizes - different XFS log types (internal and external) - different stripe size (beeing a hardware RAID5 device) The configuration of the system for tests will be : 3 x 73 GB SCSI RAID5 array (hardware), 1 x 18 GB SCSI - onboard controller. XFS will be on the single partition of the RAID array. Other than playing with log size, stripe size, log position (internal into the RAID5 array, or external on the sigle 18 gb disk) is there any other things I can do to optimize/increase I/O ? I am interested in "fast seeks" a lot more than actual I/O bandwidth. Thank you ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Oct 3 03:27:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 03:27:59 -0700 (PDT) Received: from rtsoft.rtsoft.msk.ru (Rtsoft-MTUInform-GW.mtu.ru [195.34.37.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93ARWtG016511 for ; Thu, 3 Oct 2002 03:27:46 -0700 Received: from mail by rtsoft.rtsoft.msk.ru with local (Exim 3.12 #1 (Debian)) id 17x3Ca-0004kg-00; Thu, 03 Oct 2002 14:27:28 +0400 Received: from [192.168.100.40] (helo=develop.dev.rtsoft.msk.ru) by rtsoft.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17x3CS-0004iu-00; Thu, 03 Oct 2002 14:27:22 +0400 Received: from [192.168.100.249] (helo=rtsoft.msk.ru) by develop.dev.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17x3C2-00085z-00; Thu, 03 Oct 2002 14:26:54 +0400 Message-ID: <3D9C2163.9050301@rtsoft.msk.ru> Date: Thu, 03 Oct 2002 14:52:19 +0400 From: Frasenyak Dmitrij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011031 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: tes@sagan.melbourne.sgi.com Subject: XFS test 064 race-condition ? Content-Type: multipart/mixed; boundary="------------090805050100010705050402" X-KAV: KavKeeper passed X-archive-position: 728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sed@rtsoft.msk.ru Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------090805050100010705050402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello all Test N 064 from xfs cvs repository fails under some circumstances. I can not specify the reliable way you can reproduce it. But dd if=/dev/zero of=$scratch increase chances to encounter test failure. P.S You can find 064.out and 064.out.bad in attachmet. P.P.S kernel 2.4.19-xfs xfsdump-2.2.1-0 xfsprogs-2.3.3-0 -- Thank you. Dmitrij. --------------090805050100010705050402 Content-Type: application/x-gzip; name="064.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="064.tgz" H4sIABGinD0AA+1dXXOjOBbNs3+Fap6mqzaO0Qdgv3Ul2Zqu6p7ZSXr2NUVi MqHaBpfB3Zv99SvMh4RiguyE4M4eHmKBzr1XAc65/pC447OJy8fJJjvpb5s4 ExmEn0yKrfnqOIwz92TiCe45dOJRkeM9T5yQSY9jqrdNmgVrQk7WSfLsOejq /0m3Pz8SefFXm4zcrcMgC+fk9pHIqzU6z3ej+G8yj9bhXZasH0n6mGbhkiT3 5CFYzxdR/C0lWUKiWJouwzgLFotHMt8sV+PRXWVdIcl9tAidmwcnt9i22zHU AsMsMNwCI7owVBszbcdQCwyzwHALjOjCMG3MrB1DLTDMAsMtMKILw7Ux83YM tcAwCwy3wIgujNDGLNox1ALDLDDcAiO6MK42ZrcdQy0wzALDLTCiC+NpY/ba MdQCwyww3AIjujC+Nma/HUMtMMwCwy0wogsz1cY8bcdQCwyzwHALjFCYi4Rk D6GebrbJJh1dyL+5bYkcj8ej/9yneR8hp4sJOb0nF399+dfNPz99viSnX0ia rcM0vcmCVXizDOdRQE4/Vwdl6iPX51cfv57/dvPl96+VoxnZpHmI3P82Kvl1 vo6+hzdptFwtwg+5ucyefz8qg0X4PVyQSYGWOfO3P66//v7xy+Vsp/stai5d zMjFx6+XqiOVo4qSmETzGfl08fT4IrgNFzPyixr/LwoUxQlZBiuyegjSkDjS 6lu02p6rX2VPurmVRmFK0lV4F91H4fxDmymdkbskljE2d9vLFMVRFpUXgCyi NGszZEbM1XoT5+04vJPDDdaPrSG5bplG/w1JmGbRcvseJYqrcbWaC908ieU7 kyQuL11+qoLlDkv1L8oTe5fkVzYLFUzFL9zIMc3I7399kW+ZsjBVuLPvwfqs 3DuL4u/yXs3fPpVvsBSuvukLd+UFLe7I7Y02Ib8We5N/lAc+NO+Y4lJsB/+0 o3rjFuljqzrjJD5V7+xy5xoojOc5Ro1EdWmj216THf9+fXLyC76NUvj/QHae rS28Otkzcn15fi3PhbwU85SEi2CV6qcspzq5zoJsk0roX+fnl9fXHfx3BuW/ 80Sv2rSA3Mrbdk5ySuvKcRv+vYkNTXjHYlHpwyaOw3Auz0cV9xmZKHmpmCTv vSOUBdD9LehOB6U7PZjuDugOuoPu+9KdDUp3djDdKegOuoPu+9KdD0p3fjDd GegOuoPu+9JdDEp3cTDdOegOuoPu+9LdHZTu7sF0F6A76A6670t3b1C6ewfT 3QXdQXfQfV+6+4PS3T+Y7h7oDrqD7vvSfToo3acH090H3UF30P0p3T/LOygf r+TRj4cgK6KRH3KEWbDOyI8oe5iNHLo97tSNmwe9TbU209pca4uqXYOp5oRq TqjmhGpOqOakBjDNCdOcMM0J05wwzUl9kGtOuOaEa0645oRrTlRDcyI0J0Jz IjQnQnPi1g3Nias5cTUnrubE1Zx4dUNz4mlOPM2JpznxNCd+3dCc+JoTX3Pi a058zcm0bmhOppqTqeZkqjnJp4aOPifJNyLvRO12DNZhrhtZEMXFPMFyyuh4 S4DRSOpvztU8payTJZnfj7eqPxmdSyOZLNL89t5ypUxnhUFIjGyWaX17Jana Jg2D9d2DJgDJuhijDgr/EyyjuKkSZNKAFEkpTO/W0SpXyhlpdD8kaRYHS9mq kl+je5ls4oyskijOZmYCrkHfk8Um91D1X1z+2/hXCk2Veiz3vn4yYmzP8MwY dkdqVAPc/t8GSr2FaIILwSyWqahc/CTmjq4izI6O4tLKjCVvKOWgmtTZfUVr 8X9ybWVamu9IIHU/1XtIEM+JEDJnZNvd1TrJJ9AWoq3uhTraSl720xIkg+wM 3JKcalwW3MrTKflwV3FjHqWrRfBokUdqJ1clf8xsMsrPh4x+VqSLxl6uBcYB ah5g5gFuHhCNA00H1AxBzRDUDEHNENQM0cQzMwQzQzAzBDNDMDNEs5ubIbgZ gpshuBmCmyGMPTOEMEMIM4QwQwgzhNvcM0O4ZgjXDOGaIVwzhNfcM0N4ZgjP DOGZITwzhN/cM0P4ZgjfDOGbIXwzxLS5Z4aYmiGmZoipGWKbN9uyoIMs2HsW dJAFkQXfNAu2sZ2C7b2znYLtYPtutvf0hrSN7Qxs753tDGwH23ezvafPhm1s 52B772znYDvYvpvtPX1N08Z2Abb3znYBtoPtu9ne0zembWx3wfbe2e6C7WD7 brb39ONFG9s9sL13tntgO9i+m+09/Y7YxnYfbO+d7T7YDrbvZntPP+m3sX0K tvfO9inYDrbvZntPs2vK55TebZabRZBJRpJyWOkz00+v6o7cblkabkG54+dl YU2uLq+//nF1eXPx6QoSsa9EYGLq0UhERYIukaiI8AqSsEjJ6aJyeCODjibl EoaJWsFQN6lqMtXkqinKZgWkypwqc6rMqTKnyrzqZcqcKXOmzJkyZ8q8OsSV OVfmXJlzZc6Vef2qzIUyF8pcKHOhzN3qVZm7ytxV5q4yd5W5V70qc0+Ze8rc U+aeMverV2XuK3NfmfvK3Ffm0+pVmU+V+VSZT5V5x6xKiDvmW0Lcj0PcX2WB GiQeEt+cSguJxyRbSPw7kvhXWYMMoX9nQs8g9JhfDaGH0PfxsAnI/bHJPYfc Y4I95B5yf7TPFoLov7roC4g+1llA9CH6Ryv6r/JAOUj/rqU1kH4suoH0Q/rf tfSX7Zc9S/RdJgAPCQDrsJAAkACQADoTQNl+2cOkjzMN+EgDWKCHNIA0gDTw NmmgbL+spkBPyWCKZID1m0gGSAZIBj9RMijbLyswc/Lut/GZ1M5xssnGt8G8 pxgTZyKD8JNJsTVfHYdTQU8mnuCe43iUC4l3BKUnZNLTeBrbJq9eRcjJOkmy 53Bd/T/p9udHIi/+apMVZdLCObl9JPJqjc7rqmm10pcpMrknD8F6LlPbtzSv /acV2lsUCWs8qmuuVchaq6tqgU47hlpgmAWGW2BEF4ZqY6btGGqBYRYYboER XRimjZm1Y6gFhllguAVGdGG4NmbejqEWGGaB4RYY0YUR2phFO4ZaYJgFhltg RBfG1cbstmOoBYZZYLgFRnRhPG3MXjuGWmCYBYZbYEQXxtfG7LdjqAWGWWC4 BUZ0YabamKftGGqBYRYYboERClM+V8Ws65p21KGdDFqHdvJs7VmFLj6Pv8vS so2YVZ3ZOMw/Ywbrx9aQXLfc1jkN64KvUVyNq9V8wIKzZ9+D9Vm5d1Z/6K/e YCkcCtO+RR1qZ1D+OwfXoZ6gDjXqUIPu+9KdDkp3ejDdHdAddAfd96U7G5Tu 7GC6U9AddAfd96U7H5Tu/GC6M9AddAfd96W7GJTu4mC6c9AddAfd96W7Oyjd 3YPpLkB30B1035fu3qB09w6muwu6g+6g+7509welu38w3T3QHXQH3fel+3RQ uk8PprsPuoPuoPtTun+Wd1A+XsmjHw9BVkQjP+QIs2CdkR9R9jDD8hwsz3m7 5Tmfk+QbkXeidjsG23VnUvSjuJgnWE4ZHW8J8EwBPlTiRJm9/5uVnMdWibNZ eNMxK3E6ZiVOx6zE6ZiVOLd5RD/QdEDNENQMQc0Q1AxBzRBNPDNDMDMEM0Mw MwQzQzS7uRmCmyG4GYKbIbgZwtgzQwgzhDBDCDOEMEO4zT0zhGuGcM0QrhnC NUP0VLddP9BTsWj9QE8VatsrFSILoh4hsuD7zYJQ3uNUXgrlRZlAKO9QytvT h4P2KnJgO2rFge0Dsb2nz+ntRcTAdpQKA9sHYntPX5m1V48C21EjCmwfiO09 fXvdXjAIbEdZILB9ILb39HVme3UYsB01YMD2gdje0y8L7UVAwHaU+gDbB2J7 Tz/ytVd5ANtRywFsH4jtPf3eXj4zNi/bUlZtKYeVPjMV+KruQLmXt5YITBI+ GomoSDBouZdJuZxkolaT1E2qmkw1uWpWJaEqIFXmVJlTZU6VOVXmVS9T5kyZ M2XOlDlT5tUhrsy5MufKnCtzrszrV2UulLlQ5kKZo8B7i7g7EHfMfYW4H4m4 v8piQUg8JL45lRYSj0m2kPh3JPGvsh4cQv/OhJ5B6DG/GkIPoe/jwR+Q+2OT ew65xwR7yD3k/mif8wTRf3XRFxB9rLOA6EP0j1b0X+XhfpD+XUtrIP1YdAPp h/S/a+kv2y97ruu7TAAeEgDWYSEBIAEgAXQmgLL9sgd7H2ca8JEGsEAPaQBp AGngbdJA2X5ZfYeeksEUyQDrN5EMkAyQDH6iZFC2X1bs5wQbNmzYsGHDhg0b Nmwv3P4Hgn0boABAAQA= --------------090805050100010705050402-- From owner-linux-xfs@oss.sgi.com Thu Oct 3 05:27:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 05:27:21 -0700 (PDT) Received: from w206.web2010.com (w206.web2010.com [216.157.52.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93CRJtG020228 for ; Thu, 3 Oct 2002 05:27:19 -0700 Received: from avalanche (catv-d5de8916.bp01catv.broadband.hu [213.222.137.22]) by w206.web2010.com (8.9.3/8.9.0) with ESMTP id IAA17001 for ; Thu, 3 Oct 2002 08:26:40 -0400 (EDT) Content-Type: text/plain; charset="us-ascii" From: Gabor Forgacs To: linux-xfs@oss.sgi.com Subject: O_DIRECT and linux Date: Thu, 3 Oct 2002 14:27:31 +0200 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200210031427.31322.gabor@colorfront.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g93CRJtG020229 X-archive-position: 729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Thanx for the answers to my previous question I am still tweaking with direct io under linux. I just don't know how to get the requirements for directio under irix i used the struct dioattr dio; if( -1 == fcntl( fd, F_DIOINFO, &dio)) { perror("fcntl"); exit(1); } It just doesn't work under linux, dioattr and the F_DIOINFO are undefined. I can see the O_DIRECT if i define the _GNU_SOURCE. What is the way under linux ? Thanx From owner-linux-xfs@oss.sgi.com Thu Oct 3 06:10:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 06:10:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93DA2tG025608 for ; Thu, 3 Oct 2002 06:10:02 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA96878; Thu, 3 Oct 2002 08:08:43 -0500 (CDT) Received: from [192.168.1.100] (mtv-vpn-sw-corp-0-78.corp.sgi.com [134.15.0.78]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA98489; Thu, 3 Oct 2002 08:08:43 -0500 (CDT) Subject: Re: O_DIRECT and linux From: Stephen Lord To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210031427.31322.gabor@colorfront.com> References: <200210031427.31322.gabor@colorfront.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Oct 2002 08:06:38 -0500 Message-Id: <1033650401.1053.6.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 07:27, Gabor Forgacs wrote: > Thanx for the answers to my previous question > I am still tweaking with direct io under linux. > > I just don't know how to get the requirements for directio > under irix i used the > > struct dioattr dio; > if( -1 == fcntl( fd, F_DIOINFO, &dio)) > { > perror("fcntl"); > exit(1); > } > > It just doesn't work under linux, dioattr and the F_DIOINFO are undefined. > I can see the O_DIRECT if i define the _GNU_SOURCE. > > What is the way under linux ? All the fcntl operations in Irix became ioctl calls in linux. You need to have the xfsprogs-devel package installed. All of the structures and ioctl values you need are in /usr/include/xfs/xfs_fs.h. So in this case, XFS_IOC_DIOINFO is what you need. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 3 06:27:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 06:27:13 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93DQutG030852 for ; Thu, 3 Oct 2002 06:27:06 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17x600-0004Lz-00; Thu, 03 Oct 2002 14:26:40 +0100 Date: Thu, 3 Oct 2002 14:26:39 +0100 From: Christoph Hellwig To: James Braid Cc: linux-xfs@oss.sgi.com Subject: Re: AIO and XFS? Message-ID: <20021003142639.A15094@infradead.org> References: <20021002132651.A2141@infradead.org> <018601c26a92$ceac8f20$0902000a@corp.peace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <018601c26a92$ceac8f20$0902000a@corp.peace.com>; from james.braid@peace.com on Thu, Oct 03, 2002 at 04:10:28PM +1200 X-archive-position: 731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 04:10:28PM +1200, James Braid wrote: > > > Or even better, has anyone got AIO and XFS working already? > > > > Of course it's possible. But it's not trivial. I'd suggest you wait > > for aio getting fully implemented in 2.5, you can be sure > > we'll adds supporti > > for XFS there as soon as possible. > > > > I think I kinda have XFS and AIO working now on 2.4.20pre8aa2, it is > failing on one test case, 5.t, which says that it does "- Write from a > mmap() of the same file. (5.t)". > > All I have done so far is add the following 4 lines into > fs/xfs/linux/xfs_file.c: > > .kvec_read = generic_file_kvec_read, > .kvec_write = generic_file_kvec_write, > .aio_read = generic_file_aio_read, > .aio_write = generic_file_aio_write, > > In the file_operations struct after the fsync entry in there. > Anybody got any ideas why it would be failing on that specific test > case? Because you don't have any XFS-intetrnal locks or checks. It's suprising that you got at least so far.. From owner-linux-xfs@oss.sgi.com Thu Oct 3 06:44:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 06:44:35 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93DiTtG031441 for ; Thu, 3 Oct 2002 06:44:29 -0700 Received: from laptop.americas.sgi.com (mtv-vpn-sw-corp-0-78.corp.sgi.com [134.15.0.78]) by deliverator.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 GAA05273 for ; Thu, 3 Oct 2002 06:44:28 -0700 (PDT) mail_from (lord@laptop.americas.sgi.com) Received: (from lord@localhost) by laptop.americas.sgi.com (8.11.6/8.11.6) id g93DfOP01558 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 08:41:24 -0500 Date: Thu, 3 Oct 2002 08:41:24 -0500 From: Stephen Lord Message-Id: <200210031341.g93DfOP01558@laptop.americas.sgi.com> Subject: TAKE - fix internal pagebuf counter To: linux-xfs@oss.sgi.com X-archive-position: 732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@laptop.americas.sgi.com Precedence: bulk X-list: linux-xfs fix maintenance of count of delayed write pagebufs, this is an internal counter for diagnostic purposes. Date: Thu Oct 3 06:42:47 PDT 2002 Workarea: mtv-vpn-sw-corp-0-78.corp.sgi.com:/home/lord/src/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:128986a linux/fs/xfs/pagebuf/page_buf.c - 1.64 - fix pb_delwri_cnt value from the flush path, it was leaking badly. From owner-linux-xfs@oss.sgi.com Thu Oct 3 07:25:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 07:25:07 -0700 (PDT) Received: from rose.org.uk ([195.137.41.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93EP3tG001093 for ; Thu, 3 Oct 2002 07:25:04 -0700 Received: from horace.rose.org.uk (horace.rose.org.uk [10.0.0.2]) by rose.org.uk (Postfix) with ESMTP id 1189D9D1C for ; Thu, 3 Oct 2002 15:24:58 +0100 (BST) Received: from mat by horace.rose.org.uk with local (Exim 3.36 #1 (Debian)) id 17x6uO-0001bX-00 for ; Thu, 03 Oct 2002 15:24:56 +0100 Date: Thu, 3 Oct 2002 15:24:56 +0100 From: Matthew Rose To: linux-xfs@oss.sgi.com Subject: xfsrestore bus error Message-ID: <20021003142456.GA1566@horace.rose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mat@rose.org.uk Precedence: bulk X-list: linux-xfs I have an xfs filesystem on an lvm volume on an i386 ide disk. xfsdump seems to happily work: date=`date +%y-%m-%d` xfsdump -l 0 -p 30 -L home.full.$date -M home.full.$date - /home I wanted to save the dumps to cd so I pipe the above dump into split: | split --bytes=700m - home.0.$date. then create iso9660 images and burn them. When I restore, I copy the files then cat them into xfsrestore - Should this work? At the moment cat home.0.02-10-01.a* | xfsrestore -p 30 -J -v trace - /mnt/temp/ seems happy until it suddenly returns 135 complaining of "bus error". I can't find any mention of bus error in the xfsdump-2.0.1 source or cat.c. I don't know where the message is coming from. If there is something obviously wrong with my regime then what is it? Otherwise, where do you suggest I look next? Here is the output from xfsrestore: xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0 - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: dump description: xfsrestore: hostname: homer xfsrestore: mount point: /home xfsrestore: volume: /dev/homerdata/home xfsrestore: session time: Tue Oct 1 06:52:02 2002 xfsrestore: level: 0 xfsrestore: session label: "home.full.02-10-01" xfsrestore: media label: "home.full.02-10-01" xfsrestore: file system id: d784a76e-45e9-4910-aa26-01e6b59d85d4 xfsrestore: session id: d783a9f1-808b-49c8-ad36-0f58baa610e0 xfsrestore: media id: 46e82ac2-817c-4415-b106-a9703ba0c2a7 xfsrestore: searching media for directory dump xfsrestore: dump session label: "home.full.02-10-01" xfsrestore: dump session id: d783a9f1-808b-49c8-ad36-0f58baa610e0 xfsrestore: stream 0, object 0, file 0 xfsrestore: initializing directory attributes registry xfsrestore: initializing directory entry name registry xfsrestore: initializing directory hierarchy image Bus error -- Matt Rose |Necessity is the plea for every infringement of human freedom. matt@rose.org.uk|It is the argument of tyrants; it is the creed of slaves - Pitt From owner-linux-xfs@oss.sgi.com Thu Oct 3 08:26:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 08:26:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93FPwtG007499 for ; Thu, 3 Oct 2002 08:25:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA00362 for ; Thu, 3 Oct 2002 10:25:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA11663 for ; Thu, 3 Oct 2002 10:25:52 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g93FPMD20269; Thu, 3 Oct 2002 10:25:22 -0500 Message-Id: <200210031525.g93FPMD20269@jen.americas.sgi.com> Date: Thu, 3 Oct 2002 10:25:22 -0500 Subject: TAKE - fix 2.5 kdb To: linux-xfs@oss.sgi.com X-archive-position: 734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs kdb fixes from Keith's latest version, the keyboard actually works now! Date: Thu Oct 3 08:25:01 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128990a linux/arch/i386/kernel/traps.c - 1.62 - reference boot_cpu_data correctly linux/arch/i386/vmlinux.lds.S - 1.8 - remove some ksyms code linux/arch/i386/kernel/smpboot.c - 1.49 - move disable_APIC_timer call linux/kdb/kdbsupport.c - 1.14 - small symbol table fixup linux/arch/i386/kdb/kdbasupport.c - 1.22 - reference boot_cpu_data correctly linux/drivers/serial/8250.c - 1.5 - fix serial initialization From owner-linux-xfs@oss.sgi.com Thu Oct 3 09:37:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 09:37:57 -0700 (PDT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93GbrtG011223 for ; Thu, 3 Oct 2002 09:37:54 -0700 Received: from fwd01.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17wjzs-0008Qj-01; Wed, 02 Oct 2002 15:57:04 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.255.246]) by fmrl01.sul.t-online.com with esmtp id 17wjzm-1cu7guC; Wed, 2 Oct 2002 15:56:58 +0200 Date: Wed, 2 Oct 2002 15:56:55 +0200 From: Axel Thimm To: Seth Mos Cc: Simon Matter , Bill Anderson , "Linux XFS (SGI)" Subject: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) Message-ID: <20021002155655.A7079@bonzo.nirvana> References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021002115719.C1780-100000@xs1.xs4all.nl>; from knuffie@xs4all.nl on Wed, Oct 02, 2002 at 11:58:12AM +0200 X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs On Wed, Oct 02, 2002 at 11:58:12AM +0200, Seth Mos wrote: > On Wed, 2 Oct 2002, Simon Matter wrote: > > Bill Anderson schrieb: > > > > > > On Thu, 2002-09-26 at 14:38, Florin Andrei wrote: > > > > On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74170 > The bug is CLOSED and DEFERRED. This is ugly. People will be banging SGI's doors for a RedHat installer again, and I could very well understand, that they wouldn't want to go through that again and drop supporting XFS installers/anaconda for RedHat. After all the SGI-XFS people should concentrate on kernel matters, not on anaconda. > > I'm looking forward to 8.1 :) > I think they really don't want to :-) So people using XFS and RedHat in production will have to stay with 7.3 unless SGI guys sacrifice their time again (for my personal benefit, I admit that I hope they will). :( -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Thu Oct 3 09:59:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 09:59:32 -0700 (PDT) Received: from eclectic.kluge.net (IDENT:1K4laIMstBmTg4VdVIJI88jWTddJ0GiX@eclectic.kluge.net [66.92.69.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93GxTtG012374 for ; Thu, 3 Oct 2002 09:59:29 -0700 Received: from eclectic.kluge.net (localhost [127.0.0.1]) by eclectic.kluge.net (8.12.6/8.12.6) with ESMTP id g93GxJjx018407; Thu, 3 Oct 2002 12:59:19 -0400 Received: (from felicity@localhost) by eclectic.kluge.net (8.12.6/8.12.6/Submit) id g93GxJti018405; Thu, 3 Oct 2002 12:59:19 -0400 Date: Thu, 3 Oct 2002 12:59:19 -0400 From: Theo Van Dinter To: Axel Thimm Cc: Seth Mos , Simon Matter , Bill Anderson , "Linux XFS (SGI)" Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) Message-ID: <20021003165919.GI5852@kluge.net> References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> <20021002155655.A7079@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l0l+eSofNeLXHSnY" Content-Disposition: inline In-Reply-To: <20021002155655.A7079@bonzo.nirvana> User-Agent: Mutt/1.4i X-GPG-Keyserver: http://wwwkeys.pgp.net X-GPG-Keynumber: 0xE580B363 X-GPG-Fingerprint: 75B1 F6D0 8368 38E7 A4C5 F6C2 02E3 9051 E580 B363 X-archive-position: 736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felicity@kluge.net Precedence: bulk X-list: linux-xfs --l0l+eSofNeLXHSnY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 02, 2002 at 03:56:55PM +0200, Axel Thimm wrote: > So people using XFS and RedHat in production will have to stay with 7.3 u= nless > SGI guys sacrifice their time again (for my personal benefit, I admit tha= t I > hope they will). :( Well, not really... There is more than one way to upgrade your installation. I personally copy all of the RPMs into a single directory, remove the ones I know I don't want to install (I have a personal version, etc,) then start going through "rpm -Fvh a*rpm"... If some dependency comes up, I figure out what I need to install and install it, then continue. up2date would probably work too (update redhat-release, then let it go do its thing), although I haven't tried it yet. The installer disc is nice, but it's definately not required. :) --=20 Randomly Generated Tagline: Gee, if some snot-nosed little kid sent me to prison, the first thing out, I'd find out where he lives, and tear him a new belly button. =20 -- Homer Simpson Cape Feare --l0l+eSofNeLXHSnY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9nHdnAuOQUeWAs2MRApXTAJ4m+u63yS+H7ODBfISvB1u3Ot4+WwCfYR88 95NkfbtycajIxhCHQztwxGw= =z71b -----END PGP SIGNATURE----- --l0l+eSofNeLXHSnY-- From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:00:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:00:24 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93H0MtG012556 for ; Thu, 3 Oct 2002 10:00:22 -0700 Received: (qmail 11233 invoked by uid 500); 3 Oct 2002 17:00:07 -0000 Subject: Error messages with 2.4.19-aa1 From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033664406.11038.6.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 12:00:07 -0500 X-archive-position: 737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs A box of mine crashed last night, it'd been up for > 60 days prior to this. I don't know if this is XFS related, or potentially QLogic driver related. Some initial research on Google has shown the first of the below messages relating to XFS. Could this still be a problem? TIA Oct 3 01:40:01 infdb1 kernel: Detected potential for stack overflows, stack left: 996 bytes Oct 3 01:40:01 infdb1 kernel: c9d10a94 000003e4 18076678 00000007 c70a9280 e27b5000 00000286 00000004 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:07:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:07:37 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93H7YtG013442 for ; Thu, 3 Oct 2002 10:07:34 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA78341; Thu, 3 Oct 2002 12:07:08 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 17x9RL-00045g-00; Thu, 03 Oct 2002 12:07:07 -0500 Date: Thu, 3 Oct 2002 12:07:07 -0500 From: Nathan Straz To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Error messages with 2.4.19-aa1 Message-ID: <20021003170707.GB11435@sgi.com> Mail-Followup-To: Austin Gonyou , linux-xfs@oss.sgi.com References: <1033664406.11038.6.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033664406.11038.6.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.4i X-archive-position: 738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 12:00:07PM -0500, Austin Gonyou wrote: > A box of mine crashed last night, it'd been up for > 60 days prior to > this. I don't know if this is XFS related, or potentially QLogic driver > related. > > > Oct 3 01:40:01 infdb1 kernel: Detected potential for stack overflows, > stack left: 996 bytes > Oct 3 01:40:01 infdb1 kernel: c9d10a94 000003e4 18076678 00000007 > c70a9280 e27b5000 00000286 00000004 > You'll need to decode some of those values first. I'm assuming that the error message includes some of the stack. c9d10a94 and c70a9280 are probably return addresses. Look those up in your System.map. Still, we'll need to know a lot more information than this to figure it out. Can you reproduce this? Are there any more messages in your logs? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:07:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:07:42 -0700 (PDT) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93H7ctG013480 for ; Thu, 3 Oct 2002 10:07:39 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g93H7Ie06063; Thu, 3 Oct 2002 19:07:18 +0200 Date: Thu, 3 Oct 2002 19:07:18 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Theo Van Dinter Cc: Axel Thimm , Seth Mos , Simon Matter , Bill Anderson , "Linux XFS (SGI)" Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) Message-ID: <20021003190718.D29922@vestdata.no> References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> <20021002155655.A7079@bonzo.nirvana> <20021003165919.GI5852@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021003165919.GI5852@kluge.net>; from felicity@kluge.net on Thu, Oct 03, 2002 at 12:59:19PM -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g93H7Ie06063 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g93H7etG013496 X-archive-position: 739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 12:59:19PM -0400, Theo Van Dinter wrote: > On Wed, Oct 02, 2002 at 03:56:55PM +0200, Axel Thimm wrote: > > So people using XFS and RedHat in production will have to stay with 7.3 unless > > SGI guys sacrifice their time again (for my personal benefit, I admit that I > > hope they will). :( > > Well, not really... There is more than one way to upgrade your > installation. I personally copy all of the RPMs into a single directory, > remove the ones I know I don't want to install (I have a personal > version, etc,) then start going through "rpm -Fvh a*rpm"... If some > dependency comes up, I figure out what I need to install and install it, > then continue. Apt-get is your friend :-) I've updated several servers from 7.1 to 7.3 with no real downtime. (except the time it takes to upgrade each package, and a reboot to get the new kernel). -- Ragnar Kj鴕stad From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:15:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:15:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HFBtG014404 for ; Thu, 3 Oct 2002 10:15:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA79663; Thu, 3 Oct 2002 12:15:06 -0500 (CDT) Received: from [192.168.1.101] (IDENT:zGkunEuS8+yZMSznXA5rvYWPwgoByV/A@mtv-vpn-sw-corp-0-110.corp.sgi.com [134.15.0.110]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA99452; Thu, 3 Oct 2002 12:15:04 -0500 (CDT) Subject: Re: Error messages with 2.4.19-aa1 From: Stephen Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033664406.11038.6.camel@UberGeek.coremetrics.com> References: <1033664406.11038.6.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 03 Oct 2002 12:16:47 -0500 Message-Id: <1033665409.10506.24.camel@snafu> Mime-Version: 1.0 X-archive-position: 740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 12:00, Austin Gonyou wrote: > A box of mine crashed last night, it'd been up for > 60 days prior to > this. I don't know if this is XFS related, or potentially QLogic driver > related. > > Some initial research on Google has shown the first of the below > messages relating to XFS. Could this still be a problem? > > TIA > Not sure of the timing, but we cut a lot of stuff out of the stack in various xfs functions over the last few months. It is possible that this kernel did not have those changes given how long it had been up. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:24:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:24:44 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HOftG014924 for ; Thu, 3 Oct 2002 10:24:41 -0700 Received: (qmail 11341 invoked by uid 500); 3 Oct 2002 17:24:18 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Nathan Straz Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021003170707.GB11435@sgi.com> References: <20021003170707.GB11435@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033665857.11038.17.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 12:24:18 -0500 X-archive-position: 741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs This was all that was available in the logs. :( On Thu, 2002-10-03 at 12:07, Nathan Straz wrote: > On Thu, Oct 03, 2002 at 12:00:07PM -0500, Austin Gonyou wrote: > > A box of mine crashed last night, it'd been up for > 60 days prior > to > > this. I don't know if this is XFS related, or potentially QLogic > driver > > related. > > > > > > Oct 3 01:40:01 infdb1 kernel: Detected potential for stack > overflows, > > stack left: 996 bytes > > Oct 3 01:40:01 infdb1 kernel: c9d10a94 000003e4 18076678 00000007 > > c70a9280 e27b5000 00000286 00000004 > > > > You'll need to decode some of those values first. I'm assuming that > the > error message includes some of the stack. c9d10a94 and c70a9280 are > probably return addresses. Look those up in your System.map. Still, > we'll need to know a lot more information than this to figure it out. > Can you reproduce this? Are there any more messages in your logs? > > -- > Nate Straz nstraz@sgi.com > sgi, inc http://www.sgi.com/ > Linux Test Project http://ltp.sf.net/ -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:26:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:26:08 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HQ6tG015127 for ; Thu, 3 Oct 2002 10:26:06 -0700 Received: (qmail 11353 invoked by uid 500); 3 Oct 2002 17:25:48 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033665409.10506.24.camel@snafu> References: <1033665409.10506.24.camel@snafu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033665947.11038.20.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 12:25:48 -0500 X-archive-position: 742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Ok. I will check. My goal is to hit 2.4.20 as the primary production kernel when it's ready, but I'm looking for a production -AA patch, which I think I'll have to use split patches, from AA, so long as the XFS code in -AA is up-to date with SGI. I'll take a closer look. Thanks much for your help! On Thu, 2002-10-03 at 12:16, Stephen Lord wrote: > On Thu, 2002-10-03 at 12:00, Austin Gonyou wrote: > > A box of mine crashed last night, it'd been up for > 60 days prior > to > > this. I don't know if this is XFS related, or potentially QLogic > driver > > related. > > > > Some initial research on Google has shown the first of the below > > messages relating to XFS. Could this still be a problem? > > > > TIA > > > > Not sure of the timing, but we cut a lot of stuff out of the stack > in various xfs functions over the last few months. It is possible > that this kernel did not have those changes given how long it > had been up. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:40:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:40:12 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93He6tG015956 for ; Thu, 3 Oct 2002 10:40:06 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA01453 for ; Thu, 3 Oct 2002 12:40:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA60917 for ; Thu, 3 Oct 2002 12:40:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g93HdTP22827; Thu, 3 Oct 2002 12:39:29 -0500 Message-Id: <200210031739.g93HdTP22827@jen.americas.sgi.com> Date: Thu, 3 Oct 2002 12:39:29 -0500 Subject: TAKE - kdb fix To: linux-xfs@oss.sgi.com X-archive-position: 743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fix xmount command in kdb. Date: Thu Oct 3 10:39:34 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128998a linux/fs/xfs/xfsidbg.c - 1.199 - do not deference device pointers without checking for them being set. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:45:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:45:46 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HjitG016769 for ; Thu, 3 Oct 2002 10:45:44 -0700 Received: (qmail 11401 invoked by uid 500); 3 Oct 2002 17:45:30 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Nathan Straz Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033665857.11038.17.camel@UberGeek.coremetrics.com> References: <1033665857.11038.17.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033667130.11038.22.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 12:45:30 -0500 X-archive-position: 744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I just looked these symbols up in my System.map. Nothing. Everything begins with c0, not c9 or c7. Maybe this is from the QLA2300 modules, I'm going to go look now. On Thu, 2002-10-03 at 12:24, Austin Gonyou wrote: > This was all that was available in the logs. :( > > > On Thu, 2002-10-03 at 12:07, Nathan Straz wrote: > > On Thu, Oct 03, 2002 at 12:00:07PM -0500, Austin Gonyou wrote: > > > A box of mine crashed last night, it'd been up for > 60 days prior > > to > > > this. I don't know if this is XFS related, or potentially QLogic > > driver > > > related. > > > > > > > > > Oct 3 01:40:01 infdb1 kernel: Detected potential for stack > > overflows, > > > stack left: 996 bytes > > > Oct 3 01:40:01 infdb1 kernel: c9d10a94 000003e4 18076678 00000007 > > > c70a9280 e27b5000 00000286 00000004 > > > > > > > You'll need to decode some of those values first. I'm assuming that > > the > > error message includes some of the stack. c9d10a94 and c70a9280 are > > probably return addresses. Look those up in your System.map. > Still, > > we'll need to know a lot more information than this to figure it > out. > > Can you reproduce this? Are there any more messages in your logs? > > > > -- > > Nate Straz > nstraz@sgi.com > > sgi, inc > http://www.sgi.com/ > > Linux Test Project > http://ltp.sf.net/ > -- > Austin Gonyou > Coremetrics, Inc. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:48:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:48:28 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HmQtG017246 for ; Thu, 3 Oct 2002 10:48:26 -0700 Received: (qmail 11416 invoked by uid 500); 3 Oct 2002 17:48:10 -0000 Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) From: Austin Gonyou To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= Cc: Theo Van Dinter , Axel Thimm , Seth Mos , Simon Matter , Bill Anderson , "Linux XFS \(SGI\)" In-Reply-To: <20021003190718.D29922@vestdata.no> References: <20021003190718.D29922@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1 Organization: Coremetrics, Inc. Message-Id: <1033667290.11033.24.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 12:48:10 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g93HmQtG017249 X-archive-position: 745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Can't I just do that with rpm -Fvh *? :-D On Thu, 2002-10-03 at 12:07, Ragnar Kj鴕stad wrote: > On Thu, Oct 03, 2002 at 12:59:19PM -0400, Theo Van Dinter wrote: > > On Wed, Oct 02, 2002 at 03:56:55PM +0200, Axel Thimm wrote: > > > So people using XFS and RedHat in production will have to stay > with 7.3 unless > > > SGI guys sacrifice their time again (for my personal benefit, I > admit that I > > > hope they will). :( > > > > Well, not really... There is more than one way to upgrade your > > installation. I personally copy all of the RPMs into a single > directory, > > remove the ones I know I don't want to install (I have a personal > > version, etc,) then start going through "rpm -Fvh a*rpm"... If some > > dependency comes up, I figure out what I need to install and install > it, > > then continue. > > Apt-get is your friend :-) > I've updated several servers from 7.1 to 7.3 with no real downtime. > (except the time it takes to upgrade each package, and a reboot to get > the new kernel). > > > > -- > Ragnar Kj鴕stad -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:56:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:56:13 -0700 (PDT) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93Hu9tG017760 for ; Thu, 3 Oct 2002 10:56:10 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g93HtxD08127; Thu, 3 Oct 2002 19:55:59 +0200 Date: Thu, 3 Oct 2002 19:55:59 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Austin Gonyou Cc: Theo Van Dinter , Axel Thimm , Seth Mos , Simon Matter , Bill Anderson , "Linux XFS (SGI)" Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) Message-ID: <20021003195559.E29922@vestdata.no> References: <20021003190718.D29922@vestdata.no> <1033667290.11033.24.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1033667290.11033.24.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Thu, Oct 03, 2002 at 12:48:10PM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g93HtxD08127 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g93HuBtG017761 X-archive-position: 746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 12:48:10PM -0500, Austin Gonyou wrote: > Can't I just do that with rpm -Fvh *? :-D Sure you can. I won't stop you. :-) But you may have to fiddle a little; e.g. you probably don't want to upgrade _everything_ at once (because then your server will be unavailable for a long time), so you have to find smaller subset of packages to upgrade without breaking dependencies. And if you have non redhat packages installed there may be dependancies that requires extra attention. Apt-get just helps you with the fiddeling-part. This is hardly the place for package-management discussions, but bottom-line is that it is possible to upgrade xfs-enabled redhat servers by upgrading just the rpms (skipping the RH installer) either directly with rpm or with a wrapper like apt up2date. -- Ragnar Kj鴕stad From owner-linux-xfs@oss.sgi.com Thu Oct 3 10:58:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 10:59:00 -0700 (PDT) Received: from smtp.netsigners.com (ppp-217-133-216-253.dialup.tiscali.it [217.133.216.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93HwutG018214 for ; Thu, 3 Oct 2002 10:58:57 -0700 Received: (qmail 11548 invoked from network); 3 Oct 2002 17:22:25 -0000 Received: from unknown (HELO netsigners.com) (192.168.1.4) by 192.168.1.254 with SMTP; 3 Oct 2002 17:22:25 -0000 Message-ID: <3D9C8553.2060705@netsigners.com> Date: Thu, 03 Oct 2002 19:58:43 +0200 From: stefano User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS & kernel 2.5.40 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stefano.sartini@netsigners.com Precedence: bulk X-list: linux-xfs Here is the error i got compiling latest kernel 2.5.40 Please note that removing xfs support from configure, the kernel compiles smoothly and without problems. Error: make[1]: Entering directory `/root/linux-2.5.40/init' Generating /root/linux-2.5.40/include/linux/compile.h (updated) gcc -Wp,-MD,./.version.o.d -D__KERNEL__ -I/root/linux-2.5.40/include -Wall -Ws trict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -f no-common -pipe -mpreferred-stack-boundary=2 -march=i686 -I/root/linux-2.5.40/ar ch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=version -c -o version.o version.c ld -m elf_i386 -r -o built-in.o main.o version.o do_mounts.o make[1]: Leaving directory `/root/linux-2.5.40/init' ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head .o arch/i386/kernel/init_task.o init/built-in.o --start-group arch/i386/kernel /built-in.o arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o kernel/b uilt-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o lib/li b.a arch/i386/lib/lib.a drivers/built-in.o sound/built-in.o arch/i386/pci/bu ilt-in.o net/built-in.o --end-group -o vmlinux fs/built-in.o: In function `pagebuf_queue_task': fs/built-in.o(.text+0xa0f84): undefined reference to `queue_task' fs/built-in.o: In function `pagebuf_iodone': fs/built-in.o(.text+0xa1073): undefined reference to `queue_task' fs/built-in.o: In function `pagebuf_iodone_daemon': fs/built-in.o(.text+0xa1c11): undefined reference to `TQ_ACTIVE' fs/built-in.o(.text+0xa1c39): undefined reference to `run_task_queue' make: *** [vmlinux] Error 1 GCC Version: root@dual:~/linux-2.5.40# gcc --version gcc (GCC) 3.2 System : Slackware 8.1 kernel 2.4.19-xfs thanks in advance, Stefano Sartini From owner-linux-xfs@oss.sgi.com Thu Oct 3 11:06:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 11:06:58 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93I6qtG018833 for ; Thu, 3 Oct 2002 11:06:52 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA26083; Thu, 3 Oct 2002 13:06:46 -0500 (CDT) Received: from [192.168.1.101] (IDENT:FTZIUUilekIxQyXzZ7cy2KfiNikiZyqD@mtv-vpn-sw-corp-0-110.corp.sgi.com [134.15.0.110]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA85856; Thu, 3 Oct 2002 13:06:44 -0500 (CDT) Subject: Re: XFS & kernel 2.5.40 From: Stephen Lord To: stefano Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D9C8553.2060705@netsigners.com> References: <3D9C8553.2060705@netsigners.com> Content-Type: multipart/mixed; boundary="=-CoUOtaIpUzvEnorDrmDQ" X-Mailer: Ximian Evolution 1.0.7 Date: 03 Oct 2002 13:08:26 -0500 Message-Id: <1033668508.10568.31.camel@snafu> Mime-Version: 1.0 X-archive-position: 748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs --=-CoUOtaIpUzvEnorDrmDQ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2002-10-03 at 12:58, stefano wrote: > Here is the error i got compiling latest kernel 2.5.40 > > Please note that removing xfs support from configure, the kernel > compiles smoothly and without problems. You need a patch which is our cvs tree now. Patch attached. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-CoUOtaIpUzvEnorDrmDQ Content-Disposition: attachment; filename=xfs-2.5.40.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/x-patch; name=xfs-2.5.40.patch; charset=ISO-8859-1 diff -uNr -p linux-2.5.39-mm1/fs/xfs/pagebuf/page_buf.c linux-2.5.39/fs/xfs= /pagebuf/page_buf.c --- linux-2.5.39-mm1/fs/xfs/pagebuf/page_buf.c Mon Sep 30 14:27:25 2002 +++ linux-2.5.39/fs/xfs/pagebuf/page_buf.c Mon Sep 30 16:49:06 2002 @@ -160,8 +160,6 @@ pb_tracking_free( =20 STATIC kmem_cache_t *pagebuf_cache; STATIC pagebuf_daemon_t *pb_daemon; -STATIC struct list_head pagebuf_iodone_tq[NR_CPUS]; -STATIC wait_queue_head_t pagebuf_iodone_wait[NR_CPUS]; STATIC void pagebuf_daemon_wakeup(int); =20 /* @@ -1157,15 +1155,6 @@ _pagebuf_wait_unpin( current->state =3D TASK_RUNNING; } =20 -void -pagebuf_queue_task( - struct tq_struct *task) -{ - queue_task(task, &pagebuf_iodone_tq[smp_processor_id()]); - wake_up(&pagebuf_iodone_wait[smp_processor_id()]); -} - - /* * Buffer Utility Routines */ @@ -1210,9 +1199,8 @@ pagebuf_iodone( INIT_TQUEUE(&pb->pb_iodone_sched, pagebuf_iodone_sched, (void *)pb); =20 - queue_task(&pb->pb_iodone_sched, - &pagebuf_iodone_tq[smp_processor_id()]); - wake_up(&pagebuf_iodone_wait[smp_processor_id()]); + schedule_task(&pb->pb_iodone_sched); + } else { up(&pb->pb_iodonesema); } @@ -1666,62 +1654,6 @@ pagebuf_delwri_dequeue( spin_unlock(&pb_daemon->pb_delwrite_lock); } =20 - -/* - * The pagebuf iodone daemon - */ - -STATIC int pb_daemons[NR_CPUS]; - -STATIC int -pagebuf_iodone_daemon( - void *__bind_cpu) -{ - int cpu =3D (long) __bind_cpu; - DECLARE_WAITQUEUE (wait, current); - - /* Set up the thread */ - daemonize(); - - /* Avoid signals */ - spin_lock_irq(¤t->sig->siglock); - sigfillset(¤t->blocked); - recalc_sigpending(); - spin_unlock_irq(¤t->sig->siglock); - - /* Migrate to the right CPU */ - set_cpus_allowed(current, 1UL << cpu); - if (smp_processor_id() !=3D cpu) - BUG(); - - sprintf(current->comm, "pagebuf_io_CPU%d", cpu); - INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); - init_waitqueue_head(&pagebuf_iodone_wait[cpu]); - __set_current_state(TASK_INTERRUPTIBLE); - mb(); - - pb_daemons[cpu] =3D 1; - - for (;;) { - add_wait_queue(&pagebuf_iodone_wait[cpu], - &wait); - - if (TQ_ACTIVE(pagebuf_iodone_tq[cpu])) - __set_task_state(current, TASK_RUNNING); - schedule(); - remove_wait_queue(&pagebuf_iodone_wait[cpu], - &wait); - run_task_queue(&pagebuf_iodone_tq[cpu]); - if (pb_daemons[cpu] =3D=3D 0) - break; - __set_current_state(TASK_INTERRUPTIBLE); - } - - pb_daemons[cpu] =3D -1; - wake_up_interruptible(&pagebuf_iodone_wait[cpu]); - return 0; -} - /* Defines for pagebuf daemon */ DECLARE_WAIT_QUEUE_HEAD(pbd_waitq); STATIC int force_flush; @@ -1907,8 +1839,6 @@ STATIC int pagebuf_daemon_start(void) { if (!pb_daemon) { - int cpu; - pb_daemon =3D (pagebuf_daemon_t *) kmalloc(sizeof(pagebuf_daemon_t), GFP_KERNEL); if (!pb_daemon) { @@ -1924,19 +1854,6 @@ pagebuf_daemon_start(void) =20 kernel_thread(pagebuf_daemon, (void *)pb_daemon, CLONE_FS|CLONE_FILES|CLONE_VM); - for (cpu =3D 0; cpu < NR_CPUS; cpu++) { - if (!cpu_online(cpu)) - continue; - if (kernel_thread(pagebuf_iodone_daemon, - (void *)(long) cpu, - CLONE_FS|CLONE_FILES|CLONE_VM) < 0) { - printk("pagebuf_daemon_start failed\n"); - } else { - while (!pb_daemons[cpu]) { - yield(); - } - } - } } return 0; } @@ -1950,24 +1867,12 @@ STATIC void pagebuf_daemon_stop(void) { if (pb_daemon) { - int cpu; - pb_daemon->active =3D 0; pb_daemon->io_active =3D 0; =20 wake_up_interruptible(&pbd_waitq); while (pb_daemon->active =3D=3D 0) { interruptible_sleep_on(&pbd_waitq); - } - for (cpu =3D 0; cpu < NR_CPUS; cpu++) { - if (!cpu_online(cpu)) - continue; - pb_daemons[cpu] =3D 0; - wake_up(&pagebuf_iodone_wait[cpu]); - while (pb_daemons[cpu] !=3D -1) { - interruptible_sleep_on( - &pagebuf_iodone_wait[cpu]); - } } =20 kfree(pb_daemon); diff -uNr -p linux-2.5.39-mm1/fs/xfs/pagebuf/page_buf.h linux-2.5.39/fs/xfs= /pagebuf/page_buf.h --- linux-2.5.39-mm1/fs/xfs/pagebuf/page_buf.h Mon Sep 30 14:13:46 2002 +++ linux-2.5.39/fs/xfs/pagebuf/page_buf.h Mon Sep 30 16:15:25 2002 @@ -324,9 +324,6 @@ extern void pagebuf_unlock( /* unlock b =20 #define pagebuf_geterror(pb) ((pb)->pb_error) =20 -extern void pagebuf_queue_task( - struct tq_struct *); - extern void pagebuf_iodone( /* mark buffer I/O complete */ page_buf_t *); /* buffer to mark */ =20 diff -uNr -p linux-2.5.39-mm1/fs/xfs/xfs_log.c linux-2.5.39/fs/xfs/xfs_log.c --- linux-2.5.39-mm1/fs/xfs/xfs_log.c Mon Sep 30 14:15:55 2002 +++ linux-2.5.39/fs/xfs/xfs_log.c Mon Sep 30 16:15:25 2002 @@ -2779,7 +2779,7 @@ xlog_state_release_iclog(xlog_t *log, case 0: return xlog_sync(log, iclog, 0); case 1: - pagebuf_queue_task(&iclog->ic_write_sched); + schedule_task(&iclog->ic_write_sched); } } return (0); --=-CoUOtaIpUzvEnorDrmDQ-- From owner-linux-xfs@oss.sgi.com Thu Oct 3 11:21:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 11:21:35 -0700 (PDT) Received: from darwin.libc.org (ucntcme224.dsl.micron.net [206.207.111.224] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93ILUtG020136 for ; Thu, 3 Oct 2002 11:21:30 -0700 Received: (qmail 29017 invoked from network); 3 Oct 2002 18:20:26 -0000 Received: from unknown (HELO ?192.168.1.12?) (?odUjZwFIcODEXAKJIWSeLWUA0jDefPKE?@192.168.1.12) by 192.168.1.11 with SMTP; 3 Oct 2002 18:20:26 -0000 Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) From: Bill Anderson To: Theo Van Dinter Cc: "Linux XFS (SGI)" In-Reply-To: <20021003165919.GI5852@kluge.net> References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> <20021002155655.A7079@bonzo.nirvana> <20021003165919.GI5852@kluge.net> Content-Type: text/plain Organization: Immosys Message-Id: <1033669289.7966.74.camel@locutus.libc.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1 (Preview Release) Date: 03 Oct 2002 12:21:29 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@immosys.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 10:59, Theo Van Dinter wrote: > On Wed, Oct 02, 2002 at 03:56:55PM +0200, Axel Thimm wrote: > > So people using XFS and RedHat in production will have to stay with 7.3 unless > > SGI guys sacrifice their time again (for my personal benefit, I admit that I > > hope they will). :( > > Well, not really... There is more than one way to upgrade your > installation. I personally copy all of the RPMs into a single directory, > remove the ones I know I don't want to install (I have a personal > version, etc,) then start going through "rpm -Fvh a*rpm"... If some > dependency comes up, I figure out what I need to install and install it, > then continue. > > up2date would probably work too (update redhat-release, then let it go > do its thing), although I haven't tried it yet. I have. :^) I actually did it (upgraded form 7.2 to 7.3 anyway) with Ximian as well. Works well enough so far. :) -- Bill Anderson Immosys Rebuilding the network of Tomorrow From owner-linux-xfs@oss.sgi.com Thu Oct 3 11:33:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 11:33:42 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93IXbtG020688 for ; Thu, 3 Oct 2002 11:33:37 -0700 Received: (qmail 11520 invoked by uid 500); 3 Oct 2002 18:33:02 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1033665947.11038.20.camel@UberGeek.coremetrics.com> References: <1033665947.11038.20.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033669982.11033.36.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 13:33:02 -0500 X-archive-position: 750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 12:25, Austin Gonyou wrote: > Ok. I will check. My goal is to hit 2.4.20 as the primary production > kernel when it's ready, but I'm looking for a production -AA patch, > which I think I'll have to use split patches, from AA, so long as the > XFS code in -AA is up-to date with SGI. I'll take a closer look. > > Thanks much for your help! > I've checked it out, but I don't see anything relating to c7 or c9 in the System.map or any loaded symbols from modules. > On Thu, 2002-10-03 at 12:16, Stephen Lord wrote: > > On Thu, 2002-10-03 at 12:00, Austin Gonyou wrote: > > > A box of mine crashed last night, it'd been up for > 60 days prior > > to > ... > > > Some initial research on Google has shown the first of the below > > > messages relating to XFS. Could this still be a problem? > > > > > > TIA > > > > > > > Not sure of the timing, but we cut a lot of stuff out of the stack > > in various xfs functions over the last few months. It is possible > > that this kernel did not have those changes given how long it > > had been up. > > > > Steve > > > > -- Also, just because I get a "Detected potential for stack overflows" message doesn't mean my box should blow up does it? I don't think it should, especially after doing more resaerch on google groups, seems like the messages are just warnings, but not necessarily fatal. Also, the 2.4.19-aa1 XFS code is a bit old from my understanding anway, but we've been using it for a *very* long time, and actually still use 2.4.10 kernels on some boxes, and that code is even older, without any XFS related problems. Does that seem about sane? > -- > Austin Gonyou > Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 15:10:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 15:10:36 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93MAVtG024783 for ; Thu, 3 Oct 2002 15:10:31 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA04113 for ; Thu, 3 Oct 2002 17:10:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA51782 for ; Thu, 3 Oct 2002 17:10:25 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g93M90924340; Thu, 3 Oct 2002 17:09:00 -0500 Message-Id: <200210032209.g93M90924340@stout.americas.sgi.com> Date: Thu, 3 Oct 2002 17:09:00 -0500 Subject: TAKE - Get xfs_fsr working again. X-archive-position: 751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs xfs_fsr had been broken due to restricting a RESVSP ioctl to root. In fact, even root could not defrag other user's files because it forked & did a setuid prior to calling the ioctl. This fixes things up: Remove forks from xfs_fsr. Rather than forking & setuid to the file's owner, simply run as root and chown the temp. defrag file to the original owner, to keep quota in sync. This lets root execute the RESVSP ioctl as necessary, but keeps all quota info correct when defragging another user's file. CONTRIBUTED: Chris Wedgwood Date: Thu Oct 3 15:09:14 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:129029a cmd/xfsdump/fsr/xfs_fsr.c - 1.13 - Remove forks from xfs_fsr, just run as root & chown files appropriately. CONTRIBUTED: Chris Wedgwood From owner-linux-xfs@oss.sgi.com Thu Oct 3 15:14:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 15:14:32 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93METtG025142 for ; Thu, 3 Oct 2002 15:14:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA06524 for ; Thu, 3 Oct 2002 17:14:24 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA97414 for ; Thu, 3 Oct 2002 17:14:24 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g93MCwZ24419; Thu, 3 Oct 2002 17:12:58 -0500 Message-Id: <200210032212.g93MCwZ24419@stout.americas.sgi.com> Date: Thu, 3 Oct 2002 17:12:58 -0500 Subject: TAKE - bump xfsdump version number. X-archive-position: 752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Always forget this part... Update version/changelog for fsr change Date: Thu Oct 3 15:13:34 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:129030a cmd/xfsdump/VERSION - 1.41 - Update version/changelog for fsr change cmd/xfsdump/doc/CHANGES - 1.49 - Update version/changelog for fsr change From owner-linux-xfs@oss.sgi.com Thu Oct 3 15:42:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 15:42:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93MgRtG026263 for ; Thu, 3 Oct 2002 15:42:27 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA90439 for ; Thu, 3 Oct 2002 17:42:22 -0500 (CDT) Received: from chuckle.americas.sgi.com (IDENT:Ypr+eIXMIM4tVHQbeqdJRwo0nVrxO8+n@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA82585 for ; Thu, 3 Oct 2002 17:42:21 -0500 (CDT) Received: from chuckle.americas.sgi.com (IDENT:D3GNms/VMMEe2DVBY43pahCeGrfY5s8U@localhost [127.0.0.1]) by chuckle.americas.sgi.com (8.12.5/8.11.2) with ESMTP id g93MgAKG024742 for ; Thu, 3 Oct 2002 17:42:10 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.5/8.12.5/Submit) id g93MgAws024740 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 17:42:10 -0500 Date: Thu, 3 Oct 2002 17:42:10 -0500 From: Russell Cattelan Message-Id: <200210032242.g93MgAws024740@chuckle.americas.sgi.com> Subject: TAKE - Version string update X-archive-position: 753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@sgi.com Precedence: bulk X-list: linux-xfs Set version for 1.2 prerelease Date: Thu Oct 3 15:41:50 PDT 2002 Workarea: chuckle.americas.sgi.com:/export/xfs2/x2.4-xfs-r1.2 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.2 Modid: 2.4.x-xfs-r1.2:slinx:129035a linux/fs/xfs/linux/xfs_version.h - 1.10 - Set version for 1.2 prerelease From owner-linux-xfs@oss.sgi.com Thu Oct 3 16:13:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 16:14:01 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93NDvtG027091 for ; Thu, 3 Oct 2002 16:13:57 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id NAA11328 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 13:13:56 -1000 Resent-Message-Id: <200210032313.NAA11328@otto.cfht.hawaii.edu> Date: Thu, 3 Oct 2002 12:10:23 -1000 From: Sidik Isani To: Keith Owens Cc: Sidik Isani , linux-xfs@sgi.com Subject: Re: kdb help, log recovery problems Message-ID: <20021003121023.A11133@cfht.hawaii.edu> References: <20021002191623.A8961@cfht.hawaii.edu> <4084.1033625336@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4084.1033625336@kao2.melbourne.sgi.com>; from kaos@sgi.com on Thu, Oct 03, 2002 at 04:08:56PM +1000 Resent-From: lksi@cfht.hawaii.edu Resent-Date: Thu, 3 Oct 2002 13:13:56 -1000 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 04:08:56PM +1000, Keith Owens wrote: > On Wed, 2 Oct 2002 19:16:23 -1000, > Sidik Isani wrote: > > confused by the backtrace. I read about how kdb sometimes displays > > too many arguments, but some of the valid arguments don't make > > sense. For example, xlog_do_recovery_pass() seems to be given > > either a 0 or a 1 for the "pass" argument, but the argument in > > that position has the value from the previous stack level. Am > > I not using kdb properly? I've put a more complete minicom dump > > at this URL: http://software.cfht.hawaii.edu/minicom.cap > > >0xf6b59bec 0xc02030ee xlog_do_recovery_pass+0x3e6 (0xf7cbfed4, 0x36c58, 0x0, 0x36220, 0x0) > > kernel .text 0xc0100000 0xc0202d08 0xc0203898 > > xlog_do_recovery_pass(xlog_t *log, > xfs_daddr_t head_blk, > xfs_daddr_t tail_blk, > int pass) > > head_blk and tail_blk are defined as xfs_daddr_t, 64 bit values (long > long on i386) which occupy two words on stack, with the most > significant word coming second. kdb has no idea about the parameter > types, the backtrace prints _words_. That trace shows :- > > log = 0xf7cbfed4 > head_blk = [0,0x36c58] > tail_blk = [0,0x36220] > > The default for kdb is to stop after 5 words of parameters, pass is not > being printed. At the kdb prompt 'set BTARGS 6' then backtrace. Ok. I've done that, and posted the new backtrace at the URL http://software.cfht.hawaii.edu/minicom.cap The latest versions of xfs_logprint crash on this filesystem too (and others we had created under 2.4.16). Is there anything that can be done? We're going to reformat this one, because we need to get it back into service. The output of xfs_logprint, before it blows up and consumes all the memory, was posted a couple of weeks ago. Thanks, - Sidik From owner-linux-xfs@oss.sgi.com Thu Oct 3 16:18:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 16:18:55 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93NIqtG027636 for ; Thu, 3 Oct 2002 16:18:53 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17xFF5-00025J-00; Fri, 04 Oct 2002 00:18:51 +0100 Date: Fri, 4 Oct 2002 00:18:51 +0100 From: Christoph Hellwig To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Error messages with 2.4.19-aa1 Message-ID: <20021004001851.A8002@infradead.org> References: <1033664406.11038.6.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1033664406.11038.6.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Thu, Oct 03, 2002 at 12:00:07PM -0500 X-archive-position: 755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 12:00:07PM -0500, Austin Gonyou wrote: > A box of mine crashed last night, it'd been up for > 60 days prior to > this. I don't know if this is XFS related, or potentially QLogic driver > related. > > Some initial research on Google has shown the first of the below > messages relating to XFS. Could this still be a problem? XFS uses lots of stacks and the qlogic driver even more. Plese upgrade to 2.4.20pre8aa2 and a saner storage driver. From owner-linux-xfs@oss.sgi.com Thu Oct 3 16:44:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 16:44:57 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93NittG029250 for ; Thu, 3 Oct 2002 16:44:55 -0700 Received: (qmail 14330 invoked by uid 500); 3 Oct 2002 23:44:29 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021004001851.A8002@infradead.org> References: <20021004001851.A8002@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033688669.11038.209.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 18:44:29 -0500 X-archive-position: 756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs The latest storage driver, to be released soon, uses a quarter of what the previous one did. I'm sure that will help. :-D The driver I'm using is quite sane, for production use, but...I cannot upgrade to 2.4.20pre8aa2 ATM. I'll have to do 2.4.20, + AA split patches + xfs, when the time is right. Still, the box shouldn't *crash* without much of a trace IMHO. It hasn't before now. :( On Thu, 2002-10-03 at 18:18, Christoph Hellwig wrote: > On Thu, Oct 03, 2002 at 12:00:07PM -0500, Austin Gonyou wrote: > > A box of mine crashed last night, it'd been up for > 60 days prior > to > > this. I don't know if this is XFS related, or potentially QLogic > driver > > related. > > > > Some initial research on Google has shown the first of the below > > messages relating to XFS. Could this still be a problem? > > XFS uses lots of stacks and the qlogic driver even more. > Plese upgrade to 2.4.20pre8aa2 and a saner storage driver. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 16:53:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 16:53:02 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93Nr0tG029772 for ; Thu, 3 Oct 2002 16:53:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA94374; Thu, 3 Oct 2002 18:52:55 -0500 (CDT) Received: from [192.168.1.101] (IDENT:L+V1dWiSrV71R33xADxiLMuJOCQPHtR2@mtv-vpn-sw-corp-0-110.corp.sgi.com [134.15.0.110]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA49255; Thu, 3 Oct 2002 18:52:54 -0500 (CDT) Subject: Re: Error messages with 2.4.19-aa1 From: Stephen Lord To: Austin Gonyou Cc: Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <1033688669.11038.209.camel@UberGeek.coremetrics.com> References: <20021004001851.A8002@infradead.org> <1033688669.11038.209.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 03 Oct 2002 18:54:33 -0500 Message-Id: <1033689276.15619.8.camel@snafu> Mime-Version: 1.0 X-archive-position: 757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 18:44, Austin Gonyou wrote: > The latest storage driver, to be released soon, uses a quarter of what > the previous one did. I'm sure that will help. :-D > > The driver I'm using is quite sane, for production use, but...I cannot > upgrade to 2.4.20pre8aa2 ATM. I'll have to do 2.4.20, + AA split patches > + xfs, when the time is right. > > Still, the box shouldn't *crash* without much of a trace IMHO. It hasn't > before now. > Do not forget that interrupts land on the same stack, and possibly you got hit with a bunch of networking interrupts at an unfortunate moment. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 3 17:09:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 17:09:54 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9409qtG030403 for ; Thu, 3 Oct 2002 17:09:52 -0700 Received: (qmail 15907 invoked by uid 500); 4 Oct 2002 00:09:29 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Stephen Lord Cc: Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <1033689276.15619.8.camel@snafu> References: <1033689276.15619.8.camel@snafu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033690169.11038.211.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 19:09:29 -0500 X-archive-position: 758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs True..and we're using TIGON3 NICs (bcm5700 based stuff). Grrr... On Thu, 2002-10-03 at 18:54, Stephen Lord wrote: > On Thu, 2002-10-03 at 18:44, Austin Gonyou wrote: > > The latest storage driver, to be released soon, uses a quarter of > what > > the previous one did. I'm sure that will help. :-D > > > > The driver I'm using is quite sane, for production use, but...I > cannot > > upgrade to 2.4.20pre8aa2 ATM. I'll have to do 2.4.20, + AA split > patches > > + xfs, when the time is right. > > > > Still, the box shouldn't *crash* without much of a trace IMHO. It > hasn't > > before now. > > > > Do not forget that interrupts land on the same stack, and possibly you > got hit with a bunch of networking interrupts at an unfortunate > moment. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 17:43:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 17:43:44 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g940hdtG031026 for ; Thu, 3 Oct 2002 17:43:40 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 3C33DC012DC; Fri, 4 Oct 2002 08:43:33 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 7B22DC012DC; Fri, 4 Oct 2002 08:43:22 +0800 (PHT) Date: Fri, 4 Oct 2002 08:43:22 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Hangs during filesystem recovery on mount (was: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468) Message-ID: <20021004004322.GA1785@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20020930121323.GA7250@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020930121323.GA7250@leathercollection.ph> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Scanned-By: AMaViS "Next Generation" using McAfee uvscan and ClamAV X-archive-position: 759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Hi everyone, I'm not cc'ing the lkml anymore because with something I found today I think this is fairly XFS-specific. On Mon, Sep 30, 2002 at 08:13:24PM +0800, Federico Sevilla III wrote: > After copying the oops message, I attempted to sync the disks using > the (Alt + SysRq + S) key combination and after the sync messages I > hit a kernel BUG at sched.c:568. In my sched.c (different from the XFS > tree only because of RML's preempt patch) line 568 is in the > "asmlinkage void schedule(void)" function. The oops (passed through > ksymoops) is attached as kernel-bug.out. We had an extended power outage today that the UPS couldn't handle, so our server died. On bootup, however, the system got stuck at attempting to recover /dev/sda10 during mounting. I did a reboot and went into "init=/bin/sh" to manually mount filesystems. All except /dev/sda10 -- which we mount on /opt/data and is a 54GB partition using XFS -- mounted properly. While the mount attempt was stuck at recovery I did an Alt+SysRq+S and found that all devices synced properly except 00:0a (or XX:0a, I cannot remember, but I'm sure it referred to /dev/sda10). This reminded me of the above-quoted incident. When the kernel panicked I attempted a sync and after attempting to sync the same XX:0a device it spewed out yet another panic, which I also sent an oops of. After another reboot I did an xfs_check on the yet-unrecovered /dev/sda10 and I did not get any messages. An attempt to mount it succeeded. I unmounted /dev/sda10 and did another xfs_check and again I did not get any messages, which from the manual page I've interpreted as "clean". Because /dev/sda10 was finally unmounted properly the next reboot worked and our server is back online. This is running linux-2.4-xfs CVS checked out on 20020930. The only patch is Randy Dunlap's sys-magic 20020314 which adds a /proc interface to the MagicKey. It was built using gcc 2.95.4 and runs Debian GNU/Linux. Would anyone have an idea about what's causing this? I do not know if any of the TAKEs after my checkout affect my problem, and there is pressure for me now to shift things from XFS to ext3 which I hope I won't have to do. :( Thank you for your time. :) --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Thu Oct 3 18:37:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 18:37:21 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g941bFtG031750 for ; Thu, 3 Oct 2002 18:37:15 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA86176; Thu, 3 Oct 2002 20:37:09 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id UAA60038; Thu, 3 Oct 2002 20:37:08 -0500 (CDT) Date: Thu, 3 Oct 2002 20:35:41 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Federico Sevilla III cc: Linux-XFS Mailing List Subject: Re: Hangs during filesystem recovery on mount (was: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468) In-Reply-To: <20021004004322.GA1785@leathercollection.ph> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 4 Oct 2002, Federico Sevilla III wrote: > Hi everyone, > > After another reboot I did an xfs_check on the yet-unrecovered > /dev/sda10 and I did not get any messages. An attempt to mount it > succeeded. I unmounted /dev/sda10 and did another xfs_check and again I > did not get any messages, which from the manual page I've interpreted as > "clean". Because /dev/sda10 was finally unmounted properly the next > reboot worked and our server is back online. Odd. Just to make sure I read everything right - xfs itself was hanging in recovery, and your oopses came from when you tried to sync with SysRq? And then it sounds like the only thing you did before the mount was ultimately successful, was to run xfs_check... which should be a read-only test, and should not have changed anything about the fs, as far as I know. I think the most helpful thing (in retrospect) would have been to break into kdb, and see where mount was stuck during recovery. I'm not sure what to make of this problem... -Eric From owner-linux-xfs@oss.sgi.com Thu Oct 3 19:08:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 19:08:33 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9428RtG032434 for ; Thu, 3 Oct 2002 19:08:28 -0700 Received: (qmail 16822 invoked by uid 500); 4 Oct 2002 02:08:07 -0000 Subject: Re: Hangs during filesystem recovery on mount (was: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468) From: Austin Gonyou To: Eric Sandeen Cc: Federico Sevilla III , Linux-XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033697286.11038.215.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 21:08:07 -0500 X-archive-position: 761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs This sounds very much like my problem from a few weeks ago. On Thu, 2002-10-03 at 20:35, Eric Sandeen wrote: > On Fri, 4 Oct 2002, Federico Sevilla III wrote: > > > Hi everyone, > > > > After another reboot I did an xfs_check on the yet-unrecovered > > /dev/sda10 and I did not get any messages. An attempt to mount it > > succeeded. I unmounted /dev/sda10 and did another xfs_check and > again I > > did not get any messages, which from the manual page I've > interpreted as > > "clean". Because /dev/sda10 was finally unmounted properly the next > > reboot worked and our server is back online. > > Odd. Just to make sure I read everything right - xfs itself was > hanging > in recovery, and your oopses came from when you tried to sync with > SysRq? > > And then it sounds like the only thing you did before the mount was > ultimately successful, was to run xfs_check... which should be a > read-only > test, and should not have changed anything about the fs, as far as I > know. > > I think the most helpful thing (in retrospect) would have been to > break into kdb, and see where mount was stuck during recovery. > > I'm not sure what to make of this problem... > > -Eric -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 19:22:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 19:22:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g942MRtG000503 for ; Thu, 3 Oct 2002 19:22:27 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA03230; Thu, 3 Oct 2002 21:22:22 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-36.corp.sgi.com [134.15.64.36]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA58545; Thu, 3 Oct 2002 21:22:21 -0500 (CDT) Subject: Re: Hangs during filesystem recovery on mount (was: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468) From: Stephen Lord To: Austin Gonyou Cc: Eric Sandeen , Federico Sevilla III , Linux-XFS Mailing List In-Reply-To: <1033697286.11038.215.camel@UberGeek.coremetrics.com> References: <1033697286.11038.215.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Oct 2002 21:18:53 -0500 Message-Id: <1033697935.1053.1.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-03 at 21:08, Austin Gonyou wrote: > This sounds very much like my problem from a few weeks ago. And your solution was? Or was it something which got written off? Thanks, Steve > > > > On Thu, 2002-10-03 at 20:35, Eric Sandeen wrote: > > On Fri, 4 Oct 2002, Federico Sevilla III wrote: > > > > > Hi everyone, > > > > > > After another reboot I did an xfs_check on the yet-unrecovered > > > /dev/sda10 and I did not get any messages. An attempt to mount it > > > succeeded. I unmounted /dev/sda10 and did another xfs_check and > > again I > > > did not get any messages, which from the manual page I've > > interpreted as > > > "clean". Because /dev/sda10 was finally unmounted properly the next > > > reboot worked and our server is back online. > > > > Odd. Just to make sure I read everything right - xfs itself was > > hanging > > in recovery, and your oopses came from when you tried to sync with > > SysRq? > > > > And then it sounds like the only thing you did before the mount was > > ultimately successful, was to run xfs_check... which should be a > > read-only > > test, and should not have changed anything about the fs, as far as I > > know. > > > > I think the most helpful thing (in retrospect) would have been to > > break into kdb, and see where mount was stuck during recovery. > > > > I'm not sure what to make of this problem... > > > > -Eric > -- > Austin Gonyou > Coremetrics, Inc. > From owner-linux-xfs@oss.sgi.com Thu Oct 3 19:29:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 19:29:59 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g942TvtG000989 for ; Thu, 3 Oct 2002 19:29:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA10374 for ; Thu, 3 Oct 2002 21:29:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA54856 for ; Thu, 3 Oct 2002 21:29:52 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g942SOS25922; Thu, 3 Oct 2002 21:28:24 -0500 Message-Id: <200210040228.g942SOS25922@stout.americas.sgi.com> Date: Thu, 3 Oct 2002 21:28:24 -0500 Subject: TAKE - Get xfs debug module in sync with pagebuf flags. X-archive-position: 763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Get xfs debug module back in sync with current pagebuf flags. Date: Thu Oct 3 19:29:02 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129049a linux/fs/xfs/xfsidbg.c - 1.200 - Get back in sync with current pagebuf flags. From owner-linux-xfs@oss.sgi.com Thu Oct 3 19:31:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 19:31:42 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g942VZtG001205 for ; Thu, 3 Oct 2002 19:31:38 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id C6C1FC012DD; Fri, 4 Oct 2002 10:31:29 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 59CFBC012DD; Fri, 4 Oct 2002 10:31:24 +0800 (PHT) Date: Fri, 4 Oct 2002 10:31:24 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List Subject: Re: Hangs during filesystem recovery on mount Message-ID: <20021004023124.GG1785@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List References: <20021004004322.GA1785@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Scanned-By: AMaViS "Next Generation" using McAfee uvscan and ClamAV X-archive-position: 764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 08:35:41PM -0500, Eric Sandeen wrote: > Odd. Just to make sure I read everything right - xfs itself was > hanging in recovery, and your oopses came from when you tried to sync > with SysRq? Two cases. Case 1: if system panicked (like the panics I sent ksymoops'd oopses of), Alt+SysRq+S will sync all discs until my 00:0a (/dev/sda10, /opt/data) and then send another panic (I also sent ksymoops'd oopses of this). Case 2: on bootup from an unclean shutdown, XFS hangs on mount recovery of /opt/data (/dev/sda10). While it's here, an attempt to sync will again get stuck at 00:0a, but without a panic, it will just stop. > And then it sounds like the only thing you did before the mount was > ultimately successful, was to run xfs_check... which should be a > read-only test, and should not have changed anything about the fs, as > far as I know. I booted using "init=/bin/sh" to bypass automounting, ran xfs_check on /dev/sda10 just to check -- like you I knew this was read-only and didn't expect it to change anything -- and then attempted to mount, which worked, and well... reboot after a clean unmount (and another xfs_check just to make sure). > I think the most helpful thing (in retrospect) would have been to > break into kdb, and see where mount was stuck during recovery. Ack. This system does not have kdb support built into it. :( > I'm not sure what to make of this problem... I wonder if backing up my data for this partition, doing another mkfs.xfs, and then restoring my data will help. Thoughts? Thanks everyone for your time. --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Thu Oct 3 20:04:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 20:04:46 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9434btG002567 for ; Thu, 3 Oct 2002 20:04:39 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id RAA11822 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 17:04:36 -1000 Date: Thu, 3 Oct 2002 17:04:36 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: unable to use xfs_repair Message-ID: <20021003170436.A11748@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Oct 3 16:32:10 pelmo kernel: Out of Memory: Killed process 806 (xfs_repair). Hello again - We have a bit of a problem: we have needs for very large filesystems (more than 1 TB) but no need to scale the memory in the machines the same way ... except if you ever need to run xfs_repair on the filesystem, it seems! I picked up a recent version of xfs_repair (2.3.3 that I got out of CVS a few days ago) and it consumes all of 1 GB and never finishes repairing. I can't add more swap space in a *file*, so ... well, this is a bit awkward. Is it normal for xfs_repair to consume that much memory, and can anything be done about it? Is there something strange about my filesystem causing xfs_repair to leak possibly? Ok, I scrounged some other partitions and converted them into swap, but if this is normal I guess we should consider splitting in the future to avoid grid-lock. Don't make an FS that > 1000 times available RAM? Seems nicer if we can avoid that, what do you think the practical limitations are? Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Thu Oct 3 20:06:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 20:06:53 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9436ptG002800 for ; Thu, 3 Oct 2002 20:06:51 -0700 Received: (qmail 17584 invoked by uid 500); 4 Oct 2002 03:06:06 -0000 Subject: Re: Hangs during filesystem recovery on mount (was: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468) From: Austin Gonyou To: Stephen Lord Cc: Eric Sandeen , Federico Sevilla III , Linux-XFS Mailing List In-Reply-To: <1033697935.1053.1.camel@laptop.americas.sgi.com> References: <1033697935.1053.1.camel@laptop.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033700766.11038.220.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 03 Oct 2002 22:06:06 -0500 X-archive-position: 766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I submitted some crashdumps and traces, but nothing seems to have come out of it ATM. On Thu, 2002-10-03 at 21:18, Stephen Lord wrote: > On Thu, 2002-10-03 at 21:08, Austin Gonyou wrote: > > This sounds very much like my problem from a few weeks ago. > > And your solution was? Or was it something which got written > off? > I ended up having to do xfs_repair -L. Most of the volumes were ok afterwards, but I'm still not sure *why* it happened. It did so happen though, I had bad hardware which cause the original crash at that time. The recent crash, I'm still trying to understand. > Thanks, > > Steve > > > > > > > > > On Thu, 2002-10-03 at 20:35, Eric Sandeen wrote: > > > On Fri, 4 Oct 2002, Federico Sevilla III wrote: > > > > > > > Hi everyone, > > > > > > > > After another reboot I did an xfs_check on the yet-unrecovered > > > > /dev/sda10 and I did not get any messages. An attempt to mount > it > > > > succeeded. I unmounted /dev/sda10 and did another xfs_check and > > > again I > > > > did not get any messages, which from the manual page I've > > > interpreted as > > > > "clean". Because /dev/sda10 was finally unmounted properly the > next > > > > reboot worked and our server is back online. > > > > > > Odd. Just to make sure I read everything right - xfs itself was > > > hanging > > > in recovery, and your oopses came from when you tried to sync with > > > SysRq? > > > > > > And then it sounds like the only thing you did before the mount > was > > > ultimately successful, was to run xfs_check... which should be a > > > read-only > > > test, and should not have changed anything about the fs, as far as > I > > > know. > > > > > > I think the most helpful thing (in retrospect) would have been to > > > break into kdb, and see where mount was stuck during recovery. > > > > > > I'm not sure what to make of this problem... > > > > > > -Eric > > -- > > Austin Gonyou > > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Oct 3 20:28:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 20:28:33 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g943SStG003736 for ; Thu, 3 Oct 2002 20:28:28 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.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 UAA07166 for ; Thu, 3 Oct 2002 20:28:26 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA10970; Fri, 4 Oct 2002 13:27:05 +1000 (AEST) Date: Fri, 4 Oct 2002 13:27:05 +1000 From: Tim Shimmin To: Matthew Rose Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore bus error Message-ID: <20021004132705.C399585@boing.melbourne.sgi.com> References: <20021003142456.GA1566@horace.rose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20021003142456.GA1566@horace.rose>; from mat@rose.org.uk on Thu, Oct 03, 2002 at 03:24:56PM +0100 X-archive-position: 767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Hi Matthew, On Thu, Oct 03, 2002 at 03:24:56PM +0100, Matthew Rose wrote: > I have an xfs filesystem on an lvm volume on an i386 ide disk. xfsdump > seems to happily work: > > date=`date +%y-%m-%d` > xfsdump -l 0 -p 30 -L home.full.$date -M home.full.$date - /home > > I wanted to save the dumps to cd so I pipe the above dump into split: > > | split --bytes=700m - home.0.$date. > > then create iso9660 images and burn them. > > When I restore, I copy the files then cat them into xfsrestore - > > > Should this work? Yes. I can't see why not. I just tried it and it worked for me :) > At the moment cat home.0.02-10-01.a* | xfsrestore -p > 30 -J -v trace - /mnt/temp/ seems happy until it suddenly returns 135 > complaining of "bus error". > > I can't find any mention of bus error in the xfsdump-2.0.1 source or > cat.c. I don't know where the message is coming from. > I would presume the "Bus error" is just the program crashing out from a SIGBUS signal with some address access problem such as an invalid alignment access. > If there is something obviously wrong with my regime then what is it? > Otherwise, where do you suggest I look next? > Can you email the output from xfsrestore with -v 5. You could also trying running xfsrestore in gdb and seeing where it is dying. (I'll post an SGI bug for it for the xfsdump person to look at) > Here is the output from xfsrestore: > > xfsrestore: using file dump (drive_simple) strategy > xfsrestore: version 3.0 - Running single-threaded > xfsrestore: searching media for dump > xfsrestore: examining media file 0 > xfsrestore: file 0 in object 0 of stream 0 > xfsrestore: file 0 in stream, file 0 of dump 0 on object > xfsrestore: dump description: > xfsrestore: hostname: homer > xfsrestore: mount point: /home > xfsrestore: volume: /dev/homerdata/home > xfsrestore: session time: Tue Oct 1 06:52:02 2002 > xfsrestore: level: 0 > xfsrestore: session label: "home.full.02-10-01" > xfsrestore: media label: "home.full.02-10-01" > xfsrestore: file system id: d784a76e-45e9-4910-aa26-01e6b59d85d4 > xfsrestore: session id: d783a9f1-808b-49c8-ad36-0f58baa610e0 > xfsrestore: media id: 46e82ac2-817c-4415-b106-a9703ba0c2a7 > xfsrestore: searching media for directory dump > xfsrestore: dump session label: "home.full.02-10-01" > xfsrestore: dump session id: d783a9f1-808b-49c8-ad36-0f58baa610e0 > xfsrestore: stream 0, object 0, file 0 > xfsrestore: initializing directory attributes registry > xfsrestore: initializing directory entry name registry > xfsrestore: initializing directory hierarchy image > Bus error > > --Tim From owner-linux-xfs@oss.sgi.com Thu Oct 3 20:51:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 20:51:41 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g943pctG004376 for ; Thu, 3 Oct 2002 20:51:38 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.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 UAA02944 for ; Thu, 3 Oct 2002 20:51:36 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA11446; Fri, 4 Oct 2002 13:50:18 +1000 (AEST) Date: Fri, 4 Oct 2002 13:50:18 +1000 From: Tim Shimmin To: Frasenyak Dmitrij Cc: linux-xfs@oss.sgi.com Subject: Re: XFS test 064 race-condition ? Message-ID: <20021004135017.E399585@boing.melbourne.sgi.com> References: <3D9C2163.9050301@rtsoft.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3D9C2163.9050301@rtsoft.msk.ru>; from sed@rtsoft.msk.ru on Thu, Oct 03, 2002 at 02:52:19PM +0400 X-archive-position: 768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Hi Dmitrij, Thanks for the info. I'll file an SGI bug for this for our xfsdump person. Regards, Tim. On Thu, Oct 03, 2002 at 02:52:19PM +0400, Frasenyak Dmitrij wrote: > Hello all > Test N 064 from xfs cvs repository fails under some circumstances. > I can not specify the reliable way you can reproduce it. > But dd if=/dev/zero of=$scratch increase chances to > encounter test failure. > > P.S You can find 064.out and 064.out.bad in attachmet. > > P.P.S kernel 2.4.19-xfs > xfsdump-2.2.1-0 > xfsprogs-2.3.3-0 > > > -- > Thank you. > Dmitrij. > From owner-linux-xfs@oss.sgi.com Thu Oct 3 21:05:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 21:05:37 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9445YtG004998 for ; Thu, 3 Oct 2002 21:05:35 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id SAA12001 for linux-xfs@oss.sgi.com; Thu, 3 Oct 2002 18:05:33 -1000 Date: Thu, 3 Oct 2002 18:05:33 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: mount hangs Message-ID: <20021003180533.A11986@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - I managed to get xfs_repair to clean my filesystem by adding some swap space. It reported no problems. After that, mount -o ro worked fine: XFS mounting filesystem md(9,0) Ending clean XFS mount for filesystem: md(9,0) but attempting to mount without read-only still hangs, apparently indefinitely (there's no activity on the machine.) The version of mount is 2.11u, and we're running the CVS kernel. It's a bit scary to think we're going to have to reformat all our filesystems if we need/want to upgrade beyond 2.4.16? Any idea what is going on? Again, xfs_repair now says this is a perfectly consistent filesystem, so this shouldn't be happening. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Thu Oct 3 21:11:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 21:11:35 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g944BVtG005477 for ; Thu, 3 Oct 2002 21:11:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA07174; Thu, 3 Oct 2002 23:11:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA24462; Thu, 3 Oct 2002 23:11:25 -0500 (CDT) Date: Thu, 3 Oct 2002 23:09:57 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Sidik Isani cc: linux-xfs@oss.sgi.com Subject: Re: mount hangs In-Reply-To: <20021003180533.A11986@cfht.hawaii.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs If you can get into kdb, and do: kdb> btp to see what the backtrace is, and where it's stuck, that might be helpful. -Eric On Thu, 3 Oct 2002, Sidik Isani wrote: > Hello - > > I managed to get xfs_repair to clean my filesystem by adding some > swap space. It reported no problems. After that, mount -o ro > worked fine: > > XFS mounting filesystem md(9,0) > Ending clean XFS mount for filesystem: md(9,0) > > but attempting to mount without read-only still hangs, apparently > indefinitely (there's no activity on the machine.) The version > of mount is 2.11u, and we're running the CVS kernel. It's a bit > scary to think we're going to have to reformat all our filesystems > if we need/want to upgrade beyond 2.4.16? Any idea what is going > on? Again, xfs_repair now says this is a perfectly consistent > filesystem, so this shouldn't be happening. > > Be seeing you, > > - Sidik > > From owner-linux-xfs@oss.sgi.com Thu Oct 3 21:25:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 21:25:48 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g944PjtG005996 for ; Thu, 3 Oct 2002 21:25:46 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id SAA12105; Thu, 3 Oct 2002 18:25:40 -1000 Date: Thu, 3 Oct 2002 18:25:39 -1000 From: Sidik Isani To: Eric Sandeen Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: mount hangs Message-ID: <20021003182539.A12087@cfht.hawaii.edu> References: <20021003180533.A11986@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sandeen@sgi.com on Thu, Oct 03, 2002 at 11:09:57PM -0500 X-archive-position: 771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Thu, Oct 03, 2002 at 11:09:57PM -0500, Eric Sandeen wrote: > If you can get into kdb, and do: > > kdb> btp > > to see what the backtrace is, and where it's stuck, that might be helpful. Sure. (Now that I figured out how to send a real Ctrl-A in minicom ;-) Here it is. XFS mounting filesystem md(9,0) Entering kdb (current=0xc1c12000, pid 0) on processor 1 due to Keyboard Entry [1]kdb> ps ... [1]kdb> btp 801 EBP EIP Function (args) 0xf6b51afc 0xc0118598 schedule+0x5c0 (0xf781edc4, 0xf781edc4, 0xf7e3d274, 0xf6b50000, 0xf781ee24, 0xf6b51b1c, 0x1, 0xf6b50000, 0xf781ee2c, 0xf781e) kernel .text 0xc0100000 0xc0117fd8 0xc0118740 0xf6b51b2c 0xc0107c65 __down+0xc9 (0xf781ee1c, 0x0, 0xc021b1b3) kernel .text 0xc0100000 0xc0107b9c 0xc0107d1c 0xc021b1b3 (xfs_bwrite+0x6f) 0xf6b51b40 0xc0107f7f __down_failed+0xb (0x1, 0xf6b51b64, 0xc021b1b3, 0xf781edc4, 0xf781edc4, 0x20000, 0xf7e3d274, 0xf6b51b90, 0xc01fedd8, 0xf6b4d) kernel .text 0xc0100000 0xc0107f74 0xc0107f88 0xc021b1b3 (xfs_bwrite+0x6f) 0xc01fedd8 (xlog_bwrite+0xa8) 0xc01febf3 (xlog_get_bp+0x3b) 0xc02002ee (xlog_write_log_records+0x162) 0xc0200441 (xlog_clear_stale_blocks+0x119) 0xc01ffeef (xlog_find_tail+0x3bf) 0xc0203b39 (xlog_recover+0x21) 0xc01f9907 (xfs_log_mount+0xc7) 0xc020881d (xfs_mountfs+0xa59) 0xc04c6000 (init_task_union) 0xc0480c3c (semaphore_lock) 0xc0494508 (io_request_lock) 0xc0107d12 (__down+0x176) 0xc021dfef (pagebuf_iowait+0x4f) 0xc021d069 (pagebuf_rele+0x19) 0xc02129a6 (xfs_finish_flags+0x92) 0xc0212c2c (xfs_mount+0x20c) 0xc0212a20 (xfs_mount) 0xc021f1cc .text.lock.page_buf+0xc7 kernel .text 0xc0100000 0xc021f105 0xc021f234 0xf6b51b4c 0xc021dfde pagebuf_iowait+0x3e (0xf781edc4, 0xf781edc4, 0x20000, 0xf7e3d274) kernel .text 0xc0100000 0xc021dfa0 0xc021dffc 0xf6b51b64 0xc021b1b3 xfs_bwrite+0x6f (0xf6b4d800, 0xf781edc4, 0xf781edc4, 0xf781edc4, 0xf777fe00, 0xf7760200, 0xf7780000, 0xc01febf3, 0x20000) kernel .text 0xc0100000 0xc021b144 0xc021b25c 0xc01febf3 (xlog_get_bp+0x3b) 0xf6b51b90 0xc01fedd8 xlog_bwrite+0xa8 (0xf7e3d274, 0x2, 0x100, 0xf781edc4, 0x200, 0x2, 0x0, 0xf77c18ac, 0xf7e3d274, 0x296) kernel .text 0xc0100000 0xc01fed30 0xc01fee04 0xf6b51be8 0xc02002ee xlog_write_log_records+0x162 (0xf7e3d274, 0x0, 0x2, 0x200, 0x1, 0x0, 0xf7e3d274, 0x1, 0xf6b51c9c, 0x1) kernel .text 0xc0100000 0xc020018c 0xc0200328 0xf6b51c1c 0xc0200441 xlog_clear_stale_blocks+0x119 (0xf7e3d274, 0x0, 0x1, 0xf7e3d274, 0xf7e3d274, 0xf6b51c94, 0xf7732600, 0x40000, 0x2, 0x0) kernel .text 0xc0100000 0xc0200328 0xc0200454 0xf6b51c68 0xc01ffeef xlog_find_tail+0x3bf (0xf7e3d274, 0xf6b51c94, 0xf6b51c9c, 0x0, 0xf7e3d274, 0x900, 0xf6b4d800, 0x8000, 0xf6b51c9c, 0x2) kernel .text 0xc0100000 0xc01ffb30 0xc01fff20 0xf6b51ca4 0xc0203b39 xlog_recover+0x21 (0xf7e3d274, 0x0, 0xf6b4d800, 0x40000, 0x5f800080, 0x0) kernel .text 0xc0100000 0xc0203b18 0xc0203bd8 0xf6b51cc4 0xc01f9907 xfs_log_mount+0xc7 (0xf6b4d800, 0x900, 0x5f800080, 0x0, 0x40000, 0xf6b4d800, 0x0, 0xf79c9cf8, 0xf781eef8, 0xc1c1269c) kernel .text 0xc0100000 0xc01f9840 0xc01f993c 0xc04c6000 (init_task_union) 0xc0480c3c (semaphore_lock) 0xc0494508 (io_request_lock) 0xc0107d12 (__down+0x176) 0xc021dfef (pagebuf_iowait+0x4f) 0xc021d069 (pagebuf_rele+0x19) 0xc02129a6 (xfs_finish_flags+0x92) 0xf6b51dd8 0xc020881d xfs_mountfs+0xa59 (0xf7753d84, 0xf6b4d800, 0x900, 0x0, 0xf6b4dc00, 0xf7753d84, 0xc0212a20, 0xf79c9cf8, 0x0, 0x0) kernel .text 0xc0100000 0xc0207dc4 0xc0208d80 0xc0212a20 (xfs_mount) 0xf6b51e0c 0xc0212c2c xfs_mount+0x20c (0xf7753d84, 0xf7ce6000, 0x0, 0xc0484a00, 0xf6b4dc00, 0xc048c02c, 0x202, 0x0, 0xf7ce600c, 0xf7ce6000) kernel .text 0xc0100000 0xc0212a20 0xc0212c98 0xc0484a00 (super_blocks) 0xc048c02c (xfs_fs_type) 0xc01493b0 (alloc_super+0x18) 0xc0149802 (insert_super+0x6e) 0xf6b51e80 0xc022809b linvfs_read_super+0x11f (0xf6b4dc00, 0x0, 0x0, 0xf6b4dc00, 0xc048c02c, 0xfffffff4, 0xf7d90e4c, 0xc048c02c, 0xfffffff0, 0xf6b) kernel .text 0xc0100000 0xc0227f7c 0xc02281e0 0xc048c02c (xfs_fs_type) 0xc048c02c (xfs_fs_type) 0xc048c02c (xfs_fs_type) 0xf6b51edc 0xc014a2df get_sb_bdev+0x26b (0xc048c02c, 0x0, 0xf6b4e000, 0x0, 0xf6b4f000, 0xf6b51f68, 0xf6b4f003) kernel .text 0xc0100000 0xc014a074 0xc014a378 0xc048c02c (xfs_fs_type) 0xf6b51f00 0xc014a53f do_kern_mount+0x57 (0xf6b4f000, 0x0, 0xf6b4e000, 0x0, 0x0, 0x0, 0xf6b51f68, 0xf6b50000, 0x9, 0xf77a8df8) kernel .text 0xc0100000 0xc014a4e8 0xc014a5e8 0xf6b51f34 0xc015f84d do_add_mount+0x6d (0xf6b51f68, 0xf6b4f000, 0x0, 0x0, 0xf6b4e000, 0x0, 0x0, 0xf6b50000, 0xf77de000, 0x0) kernel .text 0xc0100000 0xc015f7e0 0xc015f930 0xc015f97d (copy_mount_options+0x4d) 0xf6b51f84 0xc015fb14 do_mount+0x140 (0xf6b4e000, 0xf77de000, 0xf6b4f000, 0xc0ed0000, 0x0, 0xf6b50000, 0xc0ed0000, 0x0, 0xf6b50000, 0x0) kernel .text 0xc0100000 0xc015f9d4 0xc015fb30 0xf6b51fbc 0xc01600fc sys_mount+0xd4 (0x8059218, 0x8059228, 0x8055366, 0xc0ed0000, 0x0, 0xbffff8e8) kernel .text 0xc0100000 0xc0160028 0xc0160188 0xc0109353 system_call+0x33 kernel .text 0xc0100000 0xc0109320 0xc0109358 From owner-linux-xfs@oss.sgi.com Thu Oct 3 23:52:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Oct 2002 23:52:35 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g946qTtG008935 for ; Thu, 3 Oct 2002 23:52:30 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g946qNTE006725; Fri, 4 Oct 2002 08:52:24 +0200 (CEST) Message-Id: <4.3.2.7.2.20021004084834.0376fbb0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Oct 2002 08:51:10 +0200 To: Austin Gonyou , Stephen Lord From: Seth Mos Subject: Re: Error messages with 2.4.19-aa1 Cc: Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <1033690169.11038.211.camel@UberGeek.coremetrics.com> References: <1033689276.15619.8.camel@snafu> <1033689276.15619.8.camel@snafu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 19:09 3-10-2002 -0500, Austin Gonyou wrote: >True..and we're using TIGON3 NICs (bcm5700 based stuff). I managed to crash a box with the bcm5700 driver. I am asuming you are using a 2.0 base driver? Get the 2.2 bcm5700 driver or the tg3 driver. Both are a lot better then the previous. tg3 is in 2.4.19 already and the bcm5700 driver might be found on a site like dell support. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Oct 4 00:05:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 00:05:58 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9475rtG009553 for ; Fri, 4 Oct 2002 00:05:53 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9475kL8058785; Fri, 4 Oct 2002 09:05:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Oct 2002 09:04:33 +0200 To: Sidik Isani , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: unable to use xfs_repair In-Reply-To: <20021003170436.A11748@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 17:04 3-10-2002 -1000, Sidik Isani wrote: >Oct 3 16:32:10 pelmo kernel: Out of Memory: Killed process 806 (xfs_repair). > >Hello again - > > We have a bit of a problem: we have needs for very large filesystems > (more than 1 TB) but no need to scale the memory in the machines > the same way ... except if you ever need to run xfs_repair on the > filesystem, it seems! That isn't right. Can you run it through strace and get the top and bottom part? > I picked up a recent version of xfs_repair (2.3.3 that I got out of > CVS a few days ago) and it consumes all of 1 GB and never finishes > repairing. I can't add more swap space in a *file*, so ... well, > this is a bit awkward. Is it normal for xfs_repair to consume that > much memory, and can anything be done about it? Is there something > strange about my filesystem causing xfs_repair to leak possibly? There have been multiple fixes in both the recovery part and the xfs_repair utility and their memory usage. I have never seen this happen before. The other developers might be able to understand a strace. > Ok, I scrounged some other partitions and converted them into swap, > but if this is normal I guess we should consider splitting in the > future to avoid grid-lock. Don't make an FS that > 1000 times > available RAM? Seems nicer if we can avoid that, what do you think > the practical limitations are? There are a number of users out there with really large partitions that don't see it. How much ram does the machine actually have? The biggest I have is a 150GB partition with 256MB ram. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Oct 4 00:11:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 00:11:21 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g947BItG010051 for ; Fri, 4 Oct 2002 00:11:18 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g947B357059966; Fri, 4 Oct 2002 09:11:04 +0200 (CEST) Message-Id: <4.3.2.7.2.20021004090526.03cf6ee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Oct 2002 09:09:50 +0200 To: Sidik Isani , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: mount hangs In-Reply-To: <20021003180533.A11986@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 18:05 3-10-2002 -1000, Sidik Isani wrote: >Hello - > > but attempting to mount without read-only still hangs, apparently > indefinitely (there's no activity on the machine.) The version > of mount is 2.11u, and we're running the CVS kernel. It's a bit > scary to think we're going to have to reformat all our filesystems > if we need/want to upgrade beyond 2.4.16? Any idea what is going > on? Again, xfs_repair now says this is a perfectly consistent > filesystem, so this shouldn't be happening. The only change to the filesystem over history has been a change in the logformat. I have a box here that even saw the 2.4.0-test kernels and it still reports no problems and mounts just fine. One thing that does apply is that you _need_ to have a cleanly unmounted partition to be able to mount it with a newer kernel. And it is in the same time frame as the kernels you are using. I think something in the log-part of the filesystem may be playing up. After cleanly unmounting the filesystem you might try zerooing the log using xfs_repair -L It's a hunch though and nothing more. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Oct 4 01:41:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 01:41:38 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g948fVtG022122 for ; Fri, 4 Oct 2002 01:41:32 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id WAA12603; Thu, 3 Oct 2002 22:41:18 -1000 Date: Thu, 3 Oct 2002 22:41:18 -1000 From: Sidik Isani To: Seth Mos Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: unable to use xfs_repair Message-ID: <20021003224118.A12588@cfht.hawaii.edu> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Oct 04, 2002 at 09:04:33AM +0200 X-archive-position: 775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Fri, Oct 04, 2002 at 09:04:33AM +0200, Seth Mos wrote: > At 17:04 3-10-2002 -1000, Sidik Isani wrote: > >Oct 3 16:32:10 pelmo kernel: Out of Memory: Killed process 806 (xfs_repair). > > > >Hello again - > > > > We have a bit of a problem: we have needs for very large filesystems > > (more than 1 TB) but no need to scale the memory in the machines > > the same way ... except if you ever need to run xfs_repair on the > > filesystem, it seems! > > That isn't right. Can you run it through strace and get the top and bottom > part? Yes. I put the whole thing at: http://software.cfht.hawaii.edu/xfs_repair.strace.gz Memory usage actually jumped to almost 800 MB right away and stayed there for a while. Then it went back under 10 MB, and then to 30 for a while before exiting. > > I picked up a recent version of xfs_repair (2.3.3 that I got out of > > CVS a few days ago) and it consumes all of 1 GB and never finishes > > repairing. I can't add more swap space in a *file*, so ... well, > > this is a bit awkward. Is it normal for xfs_repair to consume that > > much memory, and can anything be done about it? Is there something > > strange about my filesystem causing xfs_repair to leak possibly? > > There have been multiple fixes in both the recovery part and the xfs_repair > utility and their memory usage. I have never seen this happen before. > > The other developers might be able to understand a strace. > > > Ok, I scrounged some other partitions and converted them into swap, > > but if this is normal I guess we should consider splitting in the > > future to avoid grid-lock. Don't make an FS that > 1000 times > > available RAM? Seems nicer if we can avoid that, what do you think > > the practical limitations are? > > There are a number of users out there with really large partitions that > don't see it. How much ram does the machine actually have? 1 GB. I added another 1.8 GB of swap, and then xfs_repair was completed in a reasonable amount of time. We know not to partition less than .1% of the disk as swap now. That's not such a sacrifice, and xfs_repair is happy. There may be good reasons it needs to grab 800 MB... it's a pretty huge filesystem. I just wanted to make sure? Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Fri Oct 4 01:46:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 01:46:09 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g948k6tG022616 for ; Fri, 4 Oct 2002 01:46:06 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id WAA12622; Thu, 3 Oct 2002 22:46:01 -1000 Date: Thu, 3 Oct 2002 22:46:00 -1000 From: Sidik Isani To: Seth Mos Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: mount hangs Message-ID: <20021003224600.B12588@cfht.hawaii.edu> References: <20021003180533.A11986@cfht.hawaii.edu> <4.3.2.7.2.20021004090526.03cf6ee8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20021004090526.03cf6ee8@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Oct 04, 2002 at 09:09:50AM +0200 X-archive-position: 776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Fri, Oct 04, 2002 at 09:09:50AM +0200, Seth Mos wrote: > At 18:05 3-10-2002 -1000, Sidik Isani wrote: > >Hello - > > > > but attempting to mount without read-only still hangs, apparently > > indefinitely (there's no activity on the machine.) The version > > of mount is 2.11u, and we're running the CVS kernel. It's a bit > > scary to think we're going to have to reformat all our filesystems > > if we need/want to upgrade beyond 2.4.16? Any idea what is going > > on? Again, xfs_repair now says this is a perfectly consistent > > filesystem, so this shouldn't be happening. > > The only change to the filesystem over history has been a change in the > logformat. I have a box here that even saw the 2.4.0-test kernels and it > still reports no problems and mounts just fine. Same here, actually. It could be a problem in software RAID5 too. I hope someone with more experience with backtraces than me can decide. > One thing that does apply is that you _need_ to have a cleanly unmounted > partition to be able to mount it with a newer kernel. And it is in the same > time frame as the kernels you are using. > > I think something in the log-part of the filesystem may be playing up. > After cleanly unmounting the filesystem you might try zerooing the log > using xfs_repair -L Yup. Without that, I couldn't even mount at all. After xfs_repair -L, I could still only mount read-only. Mounting read-write caused the strange hang even though the log has been zeroed. Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Fri Oct 4 05:10:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 05:10:20 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94CAFtG012237 for ; Fri, 4 Oct 2002 05:10:15 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA40208; Fri, 4 Oct 2002 07:10:10 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-19.corp.sgi.com [134.15.64.19]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA03618; Fri, 4 Oct 2002 07:09:51 -0500 (CDT) Subject: Re: unable to use xfs_repair From: Stephen Lord To: Sidik Isani Cc: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <20021003224118.A12588@cfht.hawaii.edu> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 07:06:00 -0500 Message-Id: <1033733203.1053.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 03:41, Sidik Isani wrote: > > Yes. I put the whole thing at: > > http://software.cfht.hawaii.edu/xfs_repair.strace.gz > > Memory usage actually jumped to almost 800 MB right away and stayed > there for a while. Then it went back under 10 MB, and then to 30 > for a while before exiting. > > > > I picked up a recent version of xfs_repair (2.3.3 that I got out of > > > CVS a few days ago) and it consumes all of 1 GB and never finishes > > > repairing. I can't add more swap space in a *file*, so ... well, > > > this is a bit awkward. Is it normal for xfs_repair to consume that > > > much memory, and can anything be done about it? Is there something > > > strange about my filesystem causing xfs_repair to leak possibly? > > > > There have been multiple fixes in both the recovery part and the xfs_repair > > utility and their memory usage. I have never seen this happen before. > > > > The other developers might be able to understand a strace. > > > > > Ok, I scrounged some other partitions and converted them into swap, > > > but if this is normal I guess we should consider splitting in the > > > future to avoid grid-lock. Don't make an FS that > 1000 times > > > available RAM? Seems nicer if we can avoid that, what do you think > > > the practical limitations are? > > > > There are a number of users out there with really large partitions that > > don't see it. How much ram does the machine actually have? > > 1 GB. I added another 1.8 GB of swap, and then xfs_repair was > completed in a reasonable amount of time. We know not to partition > less than .1% of the disk as swap now. That's not such a sacrifice, > and xfs_repair is happy. There may be good reasons it needs to > grab 800 MB... it's a pretty huge filesystem. I just wanted to > make sure? > > Be seeing you, > > - Sidik > repair does have a map of the blocks in the filesystem, we have had cases with multi-terabyte filesystems where we had to build a special binary on irix. We now ship this by default there. Unfortunately the reason for the special binary was to switch to a binary format which allows a larger address space. There are some ideas floating around about how to reduce this memory usage - looks like it is time to look harder at them. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 4 06:47:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 06:47:44 -0700 (PDT) Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94DlctG014016 for ; Fri, 4 Oct 2002 06:47:38 -0700 Received: by musuko.uchicago.edu (Postfix, from userid 1002) id D743E28B0B35; Fri, 4 Oct 2002 08:47:37 -0500 (CDT) Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) From: Stuart Luppescu To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= Cc: "Linux XFS (SGI)" In-Reply-To: <20021003190718.D29922@vestdata.no> References: <3D9A838F.8260B8AD@ch.sauter-bc.com> <20021002115719.C1780-100000@xs1.xs4all.nl> <20021002155655.A7079@bonzo.nirvana> <20021003165919.GI5852@kluge.net> <20021003190718.D29922@vestdata.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t8eL/U7GtTkfJ+wJXIBj" X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 08:47:37 -0500 Message-Id: <1033739257.14602.8.camel@musuko.uchicago.edu> Mime-Version: 1.0 X-archive-position: 778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s-luppescu@uchicago.edu Precedence: bulk X-list: linux-xfs --=-t8eL/U7GtTkfJ+wJXIBj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 2002-10-03 at 12:07, Ragnar Kj=F8rstad wrote: > On Thu, Oct 03, 2002 at 12:59:19PM -0400, Theo Van Dinter wrote: > > On Wed, Oct 02, 2002 at 03:56:55PM +0200, Axel Thimm wrote: > > > So people using XFS and RedHat in production will have to stay with 7= .3 unless > > > SGI guys sacrifice their time again (for my personal benefit, I admit= that I > > > hope they will). :( > >=20 > > Well, not really... There is more than one way to upgrade your > > installation. I personally copy all of the RPMs into a single director= y, > > remove the ones I know I don't want to install (I have a personal > > version, etc,) then start going through "rpm -Fvh a*rpm"... If some > > dependency comes up, I figure out what I need to install and install it, > > then continue. >=20 > Apt-get is your friend :-) > I've updated several servers from 7.1 to 7.3 with no real downtime. > (except the time it takes to upgrade each package, and a reboot to get > the new kernel). I used apt-get very successfully to upgrade 7.2 to 7.3, but with the switch to gcc 3.2 in 8.0 I wonder how possible this would be. --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.19-xfs-r1=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 There comes a time in the affairs of a man when he=20 has to take the bull by the tail and face the situation. -- W.C. Fields=20 =20 --=-t8eL/U7GtTkfJ+wJXIBj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9nZv5DBHcBS0tWxMRAluGAKCtrlKpEqMkU9jKD924XucyMTpvxACghsO2 4YgHI9q3ZPL0dAefFi005Ns= =fZ4b -----END PGP SIGNATURE----- --=-t8eL/U7GtTkfJ+wJXIBj-- From owner-linux-xfs@oss.sgi.com Fri Oct 4 07:58:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 07:58:55 -0700 (PDT) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94EwmtG022737 for ; Fri, 4 Oct 2002 07:58:49 -0700 Received: from there (host218-32-153-216.net-serv.com [216.153.32.218] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with SMTP id g94Ewlp22815 for ; Fri, 4 Oct 2002 10:58:47 -0400 Message-Id: <200210041458.g94Ewlp22815@webcube3.volstate.net> Content-Type: text/plain; charset="iso-8859-15" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Journal Free Space Date: Fri, 4 Oct 2002 07:56:59 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Hi Folks; Hopefully this is an easy question. I would like to know how to determine the amount of usage / free space that is left in the journal. I have several filesytems that make heavy use of extended attributes, so I would like to monitor the journal space to ensure that I don't try to overfill it. Thanks; Joe From owner-linux-xfs@oss.sgi.com Fri Oct 4 08:32:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 08:32:25 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94FWMtG024035 for ; Fri, 4 Oct 2002 08:32:22 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 3B2211E29B8; Fri, 4 Oct 2002 08:32:22 -0700 (PDT) Date: Fri, 4 Oct 2002 08:32:22 -0700 From: Chris Wedgwood To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: Journal Free Space Message-ID: <20021004153222.GB21775@tapu.f00f.org> References: <200210041458.g94Ewlp22815@webcube3.volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210041458.g94Ewlp22815@webcube3.volstate.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Oct 04, 2002 at 07:56:59AM -0500, Joe Bacom wrote: > Hopefully this is an easy question. I would like to know how to > determine the amount of usage / free space that is left in the > journal. I have several filesytems that make heavy use of extended > attributes, so I would like to monitor the journal space to ensure > that I don't try to overfill it. You can't overfill it --- worst case is that it will block and flush to disk when 'full'. In the xfsprogs distribution there is a perl script to parse and pretty-print /proc/fs/xfs which you can use to get some idea of how often this happens. --cw From owner-linux-xfs@oss.sgi.com Fri Oct 4 08:54:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 08:54:58 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94FsstG026518 for ; Fri, 4 Oct 2002 08:54:54 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA22220 for ; Fri, 4 Oct 2002 10:54:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA55627 for ; Fri, 4 Oct 2002 10:54:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94Fs6b08470; Fri, 4 Oct 2002 10:54:06 -0500 Message-Id: <200210041554.g94Fs6b08470@jen.americas.sgi.com> Date: Fri, 4 Oct 2002 10:54:06 -0500 Subject: TAKE - reduce xfs repair memory usage To: linux-xfs@oss.sgi.com X-archive-position: 781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fix size calculation bug in repairs memory allocation, reduces memory by a factor of 4. Date: Fri Oct 4 08:54:21 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:129071a cmd/xfsprogs/repair/phase4.c - 1.9 - change array size calculations cmd/xfsprogs/repair/incore.c - 1.5 - change array size calculation From owner-linux-xfs@oss.sgi.com Fri Oct 4 08:57:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 08:57:50 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94FvetG026830 for ; Fri, 4 Oct 2002 08:57:40 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA64347; Fri, 4 Oct 2002 10:57:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA47583; Fri, 4 Oct 2002 10:57:34 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94FusF08493; Fri, 4 Oct 2002 10:56:54 -0500 Subject: Re: unable to use xfs_repair From: Steve Lord To: Sidik Isani Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021003224118.A12588@cfht.hawaii.edu> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> Content-Type: multipart/mixed; boundary="=-bFKljM/LaDJQAe0OoKBn" X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 10:56:54 -0500 Message-Id: <1033747014.2457.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs --=-bFKljM/LaDJQAe0OoKBn Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2002-10-04 at 03:41, Sidik Isani wrote: > On Fri, Oct 04, 2002 at 09:04:33AM +0200, Seth Mos wrote: > > At 17:04 3-10-2002 -1000, Sidik Isani wrote: > > >Oct 3 16:32:10 pelmo kernel: Out of Memory: Killed process 806 (xfs_repair). > > > > > >Hello again - > > > > > > We have a bit of a problem: we have needs for very large filesystems > > > (more than 1 TB) but no need to scale the memory in the machines > > > the same way ... except if you ever need to run xfs_repair on the > > > filesystem, it seems! > > > > That isn't right. Can you run it through strace and get the top and bottom > > part? > > Yes. I put the whole thing at: > > http://software.cfht.hawaii.edu/xfs_repair.strace.gz > > Memory usage actually jumped to almost 800 MB right away and stayed > there for a while. Then it went back under 10 MB, and then to 30 > for a while before exiting. > OK, I went and had a look, and we are actually as efficient as we can be in use of the memory itself. Only problem is that we allocate 4 times what we use. I fixed this in cvs. Patch against previous repair code is attached. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-bFKljM/LaDJQAe0OoKBn Content-Disposition: attachment; filename=repair.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=repair.patch; charset=ISO-8859-1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: cmd/xfsprogs/repair/incore.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.8404-0/cmd/xfsprogs/repair/incore.c_1.4 Fri Oct 4 10:5= 1:31 2002 +++ cmd/xfsprogs/repair/incore.c Fri Oct 4 10:47:33 2002 @@ -72,7 +72,7 @@ setup_bmap(xfs_agnumber_t agno, xfs_agblock_t numblocks, xfs_drtbno_t rtbl= ocks) { int i; - xfs_drfsbno_t size; + size_t size =3D 0; ba_bmap =3D (__uint64_t**)malloc(agno*sizeof(__uint64_t *)); if (!ba_bmap) { @@ -80,9 +80,7 @@ return; } for (i =3D 0; i < agno; i++) { - int size; - - size =3D roundup(numblocks * (NBBY/XR_BB),sizeof(__uint64_t)); + size =3D roundup(numblocks / (NBBY/XR_BB),sizeof(__uint64_t)); ba_bmap[i] =3D (__uint64_t*)memalign(sizeof(__uint64_t), size); if (!ba_bmap[i]) { @@ -98,7 +96,7 @@ return; } - size =3D roundup(rtblocks * (NBBY/XR_BB), sizeof(__uint64_t)); + size =3D roundup(rtblocks / (NBBY/XR_BB), sizeof(__uint64_t)); rt_ba_bmap=3D(__uint64_t*)memalign(sizeof(__uint64_t), size); if (!rt_ba_bmap) { @@ -178,7 +176,7 @@ * for now, initialize all realtime blocks to be free * (state =3D=3D XR_E_FREE) */ - size =3D howmany(num * (NBBY/XR_BB), sizeof(__uint64_t)); + size =3D howmany(num / (NBBY/XR_BB), sizeof(__uint64_t)); for (j =3D 0; j < size; j++) rt_ba_bmap[j] =3D 0x2222222222222222LL; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: cmd/xfsprogs/repair/phase4.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.8404-0/cmd/xfsprogs/repair/phase4.c_1.8 Fri Oct 4 10:5= 1:31 2002 +++ cmd/xfsprogs/repair/phase4.c Fri Oct 4 10:07:49 2002 @@ -1294,7 +1294,7 @@ /* * now reset the bitmap for all ags */ - bzero(ba_bmap[i], roundup(mp->m_sb.sb_agblocks*(NBBY/XR_BB), + bzero(ba_bmap[i], roundup(mp->m_sb.sb_agblocks/(NBBY/XR_BB), sizeof(__uint64_t))); for (j =3D 0; j < ag_hdr_block; j++) set_agbno_state(mp, i, j, XR_E_INUSE_FS); --=-bFKljM/LaDJQAe0OoKBn-- From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:09:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:09:59 -0700 (PDT) Received: from www.llamacom.com (www1.llamacom.com [216.51.145.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94G9rtG027695 for ; Fri, 4 Oct 2002 09:09:53 -0700 Received: (qmail 28472 invoked by uid 900); 4 Oct 2002 16:09:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Oct 2002 16:09:52 -0000 Date: Fri, 4 Oct 2002 11:09:52 -0500 (CDT) From: Craig Soucie X-X-Sender: x98black@www.llamacom.com To: linux-xfs@oss.sgi.com Subject: Re: Journal Free Space In-Reply-To: <20021004153222.GB21775@tapu.f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: x98black@blackglass.com Precedence: bulk X-list: linux-xfs So, if I have a partition that is a certain size and is holding my external journal, I'm cool? What happens when it fills up, does this hose my fs or is there a mechanism to deal with that? Craig On Fri, 4 Oct 2002, Chris Wedgwood wrote: > On Fri, Oct 04, 2002 at 07:56:59AM -0500, Joe Bacom wrote: > > > Hopefully this is an easy question. I would like to know how to > > determine the amount of usage / free space that is left in the > > journal. I have several filesytems that make heavy use of extended > > attributes, so I would like to monitor the journal space to ensure > > that I don't try to overfill it. > > You can't overfill it --- worst case is that it will block and flush > to disk when 'full'. In the xfsprogs distribution there is a perl > script to parse and pretty-print /proc/fs/xfs which you can use to get > some idea of how often this happens. > > > > --cw > > > -- Craig Soucie BlackGlass Inc. craigs@blackglass.com From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:19:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:19:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GJqtG028270 for ; Fri, 4 Oct 2002 09:19:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA63736 for ; Fri, 4 Oct 2002 11:19:47 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA18631 for ; Fri, 4 Oct 2002 11:19:47 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g94GIE130501; Fri, 4 Oct 2002 11:18:14 -0500 Message-Id: <200210041618.g94GIE130501@stout.americas.sgi.com> Date: Fri, 4 Oct 2002 11:18:14 -0500 Subject: TAKE - Bump version, document xfs_repair memory allocation fix. X-archive-position: 784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Oct 4 09:19:29 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:129073a cmd/xfsprogs/VERSION - 1.59 - Bump version, document xfs_repair memory allocation fix. cmd/xfsprogs/doc/CHANGES - 1.84 - Bump version, document xfs_repair memory allocation fix. From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:21:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:22:00 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GLvtG028481 for ; Fri, 4 Oct 2002 09:21:57 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id EC4BF14862; Fri, 4 Oct 2002 18:21:51 +0200 (MEST) Date: Fri, 4 Oct 2002 18:21:51 +0200 From: Andi Kleen To: Steve Lord Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: unable to use xfs_repair Message-ID: <20021004182151.A8443@wotan.suse.de> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> <1033747014.2457.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033747014.2457.11.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > OK, I went and had a look, and we are actually as efficient as we can > be in use of the memory itself. Only problem is that we allocate 4 times > what we use. I fixed this in cvs. Unless you memset it (=actually using, not allocating) and it still fits into the 32big address space that could be worked around by echo 1 > /proc/sys/vm/overcommit_memory -Andi From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:26:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:27:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GQvtG029226 for ; Fri, 4 Oct 2002 09:26:58 -0700 Received: (qmail 7373 invoked by uid 0); 4 Oct 2002 16:26:50 -0000 Received: from pd903c3a2.dip.t-dialin.net (HELO gmx.de) (217.3.195.162) by mail.gmx.net (mp020-rz3) with SMTP; 4 Oct 2002 16:26:50 -0000 Message-ID: <3D9DC08B.8080502@gmx.de> Date: Fri, 04 Oct 2002 18:23:39 +0200 From: Michael Wahlbrink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Journal Free Space References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mimi.ka@gmx.de Precedence: bulk X-list: linux-xfs Craig Soucie wrote: > So, if I have a partition that is a certain size and is holding my > external journal, I'm cool? What happens when it fills up, does this hose > my fs or is there a mechanism to deal with that? > > Craig As I understand the function of the XFS jurnal it only holds the changes of the metadata and not the data itself. If it get filled up (also as an externel partition), the disks will be synced. So it only slows down if the Journal filled up... hth regards micha From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:30:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:30:40 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GUctG029672 for ; Fri, 4 Oct 2002 09:30:38 -0700 Received: (qmail 20184 invoked by uid 500); 4 Oct 2002 16:30:22 -0000 Subject: Re: RedHat 8.0 and XFS, the sad story continues ... (was: Begging :^)) From: Austin Gonyou To: Stuart Luppescu Cc: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= , "Linux XFS \(SGI\)" In-Reply-To: <1033739257.14602.8.camel@musuko.uchicago.edu> References: <1033739257.14602.8.camel@musuko.uchicago.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033749021.19763.13.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 04 Oct 2002 11:30:22 -0500 X-archive-position: 787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 08:47, Stuart Luppescu wrote: So long as you get glibc and gcc-lib in there, plus associated dependancies...it should work fine. > > I used apt-get very successfully to upgrade 7.2 to 7.3, but with the > switch to gcc 3.2 in 8.0 I wonder how possible this would be. > -- > Stuart Luppescu -=- s-luppescu@uchicago.edu > University of Chicago -=- CCSR > $B:MJ8$HCRF`H~$NIc(B -=- Kernel 2.4.19-xfs-r1 > There comes a time in the affairs of a man when he > has to take the bull by the tail and face the > situation. -- W.C. Fields > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:45:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:45:25 -0700 (PDT) Received: from vivaldi.controlnet.com (hidden-user@fwextcnus.controlnet.com [12.44.181.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GjNtG030501 for ; Fri, 4 Oct 2002 09:45:23 -0700 Received: from mknecht (unknown [192.168.10.181]) by vivaldi.controlnet.com (Postfix on SuSE eMail Server 2.0) with SMTP id 563223EF9A for ; Fri, 4 Oct 2002 09:51:28 -0700 (PDT) From: "Mark Knecht" To: Subject: 1st message - xfs as a module under RH 7.3 Date: Fri, 4 Oct 2002 09:42:02 -0700 Message-ID: <000501c26bc4$f8352630$b50aa8c0@mknecht> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mknecht@controlnet.com Precedence: bulk X-list: linux-xfs Hi, Test message. Just subscribed. I am running a custom Linux kernel (2.4.19-ll) that I did not compile, so I can't rebuild it quickly to try out XFS. I'd like to find out if XFS can be loaded as a module so that I could do some testing for real-time audio applications. If so, then what's the best way to proceed? Are there RPMs? I can't find one. If I should build from CVS, that's fine, but I'd like to get some instructions on how to load the modules. Thanks, Mark From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:44:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:44:59 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GiqtG030410 for ; Fri, 4 Oct 2002 09:44:53 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA73420; Fri, 4 Oct 2002 11:44:46 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA76292; Fri, 4 Oct 2002 11:44:46 -0500 (CDT) Subject: Re: Journal Free Space From: Eric Sandeen To: Craig Soucie Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Oct 2002 11:43:13 -0500 Message-Id: <1033749793.27363.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I'll repost the message I sent when Joe sent his question the first time... :) > I'm not sure you're thinking about it quite right, you can't technically > "overfill" your log. It's designed so that when it's full, metadata in > memory is flushed to disk, so that you can use more log space. -Eric On Fri, 2002-10-04 at 11:09, Craig Soucie wrote: > So, if I have a partition that is a certain size and is holding my > external journal, I'm cool? What happens when it fills up, does this hose > my fs or is there a mechanism to deal with that? > > Craig -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:45:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:45:40 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GjbtG030623 for ; Fri, 4 Oct 2002 09:45:38 -0700 Received: from funky (eaganfw1.sgi.com [198.149.7.1]) by lips.thebarn.com (8.12.6/8.12.4) with ESMTP id g94Gja0d001301 for ; Fri, 4 Oct 2002 11:45:36 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: 1.2 PreRelease avaliable From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 20:15:19 -0500 Message-Id: <1033780525.2804.41.camel@funky> Mime-Version: 1.0 X-archive-position: 790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Ok so we are making progress toward actually getting a 1.2 release ready. ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/ Currently the for this pre-release only a single patch'em all patch is available. The command are split up as usual into rpm's src.rpm's and tar balls. We are still chasing several bugs in this code base, they are very obscure end case problems so most people won't hit them. Please pound on, run over, throw things etc and report problems, success weather conditions. The installer iso is also available. I will install a system that looks and feels similar to a RedHat (tm) 8.0 system. NOTE NOTE NOTE This is probably going to be the only spin of the installer iso, as the amount of effort is not trivial. A few known problems exist and will probably not be fixed unless somebody wants to send in a fix. 1) Grud does not install correctly during the install, anybody wishing to use grub should select lilo initially for the boot loader and them install grub once the system is up. 2) Upgrades on system with labels in the fstab do not work, this is problem with anaconda and is not easily fixed. The workaround for this is to change the fstab to contain the actual device names before attempting the upgrade. 3) The text version of the installer is not able to do partitioning. This is probably a trivial bug in anaconda but we just don't have time to look at it. -Russell Cattelan From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:45:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:45:47 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GjjtG030650 for ; Fri, 4 Oct 2002 09:45:45 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA71631; Fri, 4 Oct 2002 11:45:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA58469; Fri, 4 Oct 2002 11:45:38 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94Giv309713; Fri, 4 Oct 2002 11:44:57 -0500 Subject: Re: unable to use xfs_repair From: Steve Lord To: Andi Kleen Cc: Sidik Isani , linux-xfs@oss.sgi.com In-Reply-To: <20021004182151.A8443@wotan.suse.de> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> <1033747014.2457.11.camel@jen.americas.sgi.com> <20021004182151.A8443@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 11:44:57 -0500 Message-Id: <1033749897.6896.20.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 11:21, Andi Kleen wrote: > > OK, I went and had a look, and we are actually as efficient as we can > > be in use of the memory itself. Only problem is that we allocate 4 times > > what we use. I fixed this in cvs. > > Unless you memset it (=actually using, not allocating) and it still > fits into the 32big address space that could be worked around by > echo 1 > /proc/sys/vm/overcommit_memory It uses all the memory, 4 bits per filesystem block, we record what type of information is in that part of the fs - including free blocks. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:47:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:47:55 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GlqtG031349 for ; Fri, 4 Oct 2002 09:47:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA71242 for ; Fri, 4 Oct 2002 11:47:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA90050 for ; Fri, 4 Oct 2002 11:47:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94Gl6K09757; Fri, 4 Oct 2002 11:47:06 -0500 Message-Id: <200210041647.g94Gl6K09757@jen.americas.sgi.com> Date: Fri, 4 Oct 2002 11:47:06 -0500 Subject: TAKE - fix kdb extent printing To: linux-xfs@oss.sgi.com X-archive-position: 792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs This got broken when we turned off large filesystem (> 2Tbytes) in the build. Date: Fri Oct 4 09:46:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129079a linux/fs/xfs/xfsidbg.c - 1.201 - rework extent printing code From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:50:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:50:28 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GoQtG032550 for ; Fri, 4 Oct 2002 09:50:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA71735; Fri, 4 Oct 2002 11:50:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA61766; Fri, 4 Oct 2002 11:49:44 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94Gn3m09765; Fri, 4 Oct 2002 11:49:03 -0500 Subject: Re: Journal Free Space From: Steve Lord To: joebacom@volstate.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210041458.g94Ewlp22815@webcube3.volstate.net> References: <200210041458.g94Ewlp22815@webcube3.volstate.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 11:49:03 -0500 Message-Id: <1033750143.6896.26.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 07:56, Joe Bacom wrote: > Hi Folks; > > Hopefully this is an easy question. I would like to know how to determine > the amount of usage / free space that is left in the journal. I have several > filesytems that make heavy use of extended attributes, so I would like to > monitor the journal space to ensure that I don't try to overfill it. > Sending this out since folks are getting confused.... The xfs journal (or log, it is called log in the code), is basically a circular on disk buffer. Metadata changes are recorded into the log, and subsequently the real metadata is flushed to disk. The benefits of having a log is we write all the changes which make the filesystem move from one consistent state to another out into the log in one go rather than having to sync up several writes to different parts of the disk. Those writes out to the real metadata happen later, but we do not care at all about the order they happen in. So we perform some transactions, these are written to the log, and our location in the log keeps moving, eventually wrapping around. Normally before we wrap the metadata modified in a transaction has been flushed to disk, so we can just reuse the space. If we are modifying the filesystem faster than metadata can be flushed to disk then new operations which need log space have to force the old metadata out to disk first. So you cannot 'run out' of log space, but you can get into the mode we call tail pushing where the head of the log is always bumping into the tail. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:54:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:54:18 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GsGtG000796 for ; Fri, 4 Oct 2002 09:54:16 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA55417; Fri, 4 Oct 2002 11:54:11 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA68868; Fri, 4 Oct 2002 11:54:10 -0500 (CDT) Subject: Re: 1st message - xfs as a module under RH 7.3 From: Eric Sandeen To: Mark Knecht Cc: linux-xfs@oss.sgi.com In-Reply-To: <000501c26bc4$f8352630$b50aa8c0@mknecht> References: <000501c26bc4$f8352630$b50aa8c0@mknecht> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Oct 2002 11:52:37 -0500 Message-Id: <1033750357.29856.31.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 11:42, Mark Knecht wrote: > Hi, > Test message. Just subscribed. > > I am running a custom Linux kernel (2.4.19-ll) that I did not compile, so > I can't rebuild it quickly to try out XFS. > > I'd like to find out if XFS can be loaded as a module so that I could do > some testing for real-time audio applications. xfs can be built as a module, but that module depends on things not in the standard 2.4 kernel. So you'll need to build an xfs-capable kernel in any case. > If so, then what's the best way to proceed? Are there RPMs? I can't find > one. If I should build from CVS, that's fine, but I'd like to get some > instructions on how to load the modules. Did you look on ftp://oss.sgi.com/projects/xfs/download for rpms? There are kernel rpms there for every official release. -Eric From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:55:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:55:13 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GtAtG000930 for ; Fri, 4 Oct 2002 09:55:10 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id F2FD214849; Fri, 4 Oct 2002 18:55:04 +0200 (MEST) Date: Fri, 4 Oct 2002 18:55:04 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: unable to use xfs_repair Message-ID: <20021004185504.B16379@wotan.suse.de> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> <1033747014.2457.11.camel@jen.americas.sgi.com> <20021004182151.A8443@wotan.suse.de> <1033749897.6896.20.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033749897.6896.20.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Fri, Oct 04, 2002 at 11:44:57AM -0500, Steve Lord wrote: > On Fri, 2002-10-04 at 11:21, Andi Kleen wrote: > > > OK, I went and had a look, and we are actually as efficient as we can > > > be in use of the memory itself. Only problem is that we allocate 4 times > > > what we use. I fixed this in cvs. > > > > Unless you memset it (=actually using, not allocating) and it still > > fits into the 32big address space that could be worked around by > > echo 1 > /proc/sys/vm/overcommit_memory > > It uses all the memory, 4 bits per filesystem block, we record what > type of information is in that part of the fs - including free blocks. When it allocates more than it actually faults in then this tweak may help. -Andi From owner-linux-xfs@oss.sgi.com Fri Oct 4 09:58:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 09:58:52 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94GwotG001784 for ; Fri, 4 Oct 2002 09:58:50 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 09:59:28 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B01015A55@nasexs1.meridian-data.com> From: Marc Kaplan To: linux-xfs@oss.sgi.com Subject: xfs_fsr usage Date: Fri, 4 Oct 2002 09:59:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc.kaplan@quantum.com Precedence: bulk X-list: linux-xfs Hello, Our NAS product has an XFS file system on top of RAID and LVM, but we never run xfs_fsr. I have a few questions about xfs_fsr: 1. Should we be running xfs_fsr periodically? 2. If we continue not to use xfs_fsr will the file system become heavily fragmented over time? 3. Has anybody ever experienced any file system corruption using xfs_fsr? 4. By reading the man page it seems that xfs_fsr just runs for a certain amount of time, is there an option to have it run until all the file systems specified by -m are defragmented? Thanks, -Marc From owner-linux-xfs@oss.sgi.com Fri Oct 4 10:02:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 10:02:34 -0700 (PDT) Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94H2WtG002300 for ; Fri, 4 Oct 2002 10:02:32 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) 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 KAA07820 for ; Fri, 4 Oct 2002 10:03:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA74617; Fri, 4 Oct 2002 12:01:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA79139; Fri, 4 Oct 2002 12:01:32 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94H0pb10149; Fri, 4 Oct 2002 12:00:51 -0500 Subject: Re: unable to use xfs_repair From: Steve Lord To: Andi Kleen Cc: Sidik Isani , linux-xfs@oss.sgi.com In-Reply-To: <20021004185504.B16379@wotan.suse.de> References: <20021003170436.A11748@cfht.hawaii.edu> <4.3.2.7.2.20021004090036.036b5728@pop.xs4all.nl> <20021003224118.A12588@cfht.hawaii.edu> <1033747014.2457.11.camel@jen.americas.sgi.com> <20021004182151.A8443@wotan.suse.de> <1033749897.6896.20.camel@jen.americas.sgi.com> <20021004185504.B16379@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 12:00:51 -0500 Message-Id: <1033750851.2457.30.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 11:55, Andi Kleen wrote: > On Fri, Oct 04, 2002 at 11:44:57AM -0500, Steve Lord wrote: > > On Fri, 2002-10-04 at 11:21, Andi Kleen wrote: > > > > OK, I went and had a look, and we are actually as efficient as we can > > > > be in use of the memory itself. Only problem is that we allocate 4 times > > > > what we use. I fixed this in cvs. > > > > > > Unless you memset it (=actually using, not allocating) and it still > > > fits into the 32big address space that could be worked around by > > > echo 1 > /proc/sys/vm/overcommit_memory > > > > It uses all the memory, 4 bits per filesystem block, we record what > > type of information is in that part of the fs - including free blocks. > > When it allocates more than it actually faults in then this tweak may help. Well, a 1 Tbyte filesystem with 4K blocks went from needing 256Mbytes to hold block information to 64Mbytes, so in some setups it is the difference between running out of memory and not. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 4 10:12:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 10:12:46 -0700 (PDT) Received: from vivaldi.controlnet.com (hidden-user@fwextcnus.controlnet.com [12.44.181.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94HCitG002900 for ; Fri, 4 Oct 2002 10:12:44 -0700 Received: from mknecht (unknown [192.168.10.181]) by vivaldi.controlnet.com (Postfix on SuSE eMail Server 2.0) with SMTP id 799C33EF9A; Fri, 4 Oct 2002 10:18:48 -0700 (PDT) From: "Mark Knecht" To: "'Eric Sandeen'" Cc: Subject: RE: 1st message - xfs as a module under RH 7.3 Date: Fri, 4 Oct 2002 10:09:20 -0700 Message-ID: <000601c26bc8$c992d670$b50aa8c0@mknecht> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <1033750357.29856.31.camel@stout.americas.sgi.com> X-archive-position: 798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mknecht@controlnet.com Precedence: bulk X-list: linux-xfs Eric, I'll search through the ftp site. I just needed the pointer. Thanks. As per your message, it looks like I'll have to beg the kernel builders to add xfs support though, so I might as well just have them build the stuff into the kernel anyway. If they do that, then no modules would be needed I guess. (I'm not a programmer or a Linux guy really. Just a user who's managed to get vfat, ext2, ext3 and reiser working...) Thanks, Mark -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Friday, October 04, 2002 9:53 AM To: Mark Knecht Cc: linux-xfs@oss.sgi.com Subject: Re: 1st message - xfs as a module under RH 7.3 On Fri, 2002-10-04 at 11:42, Mark Knecht wrote: > Hi, > Test message. Just subscribed. > > I am running a custom Linux kernel (2.4.19-ll) that I did not compile, so > I can't rebuild it quickly to try out XFS. > > I'd like to find out if XFS can be loaded as a module so that I could do > some testing for real-time audio applications. xfs can be built as a module, but that module depends on things not in the standard 2.4 kernel. So you'll need to build an xfs-capable kernel in any case. > If so, then what's the best way to proceed? Are there RPMs? I can't find > one. If I should build from CVS, that's fine, but I'd like to get some > instructions on how to load the modules. Did you look on ftp://oss.sgi.com/projects/xfs/download for rpms? There are kernel rpms there for every official release. -Eric From owner-linux-xfs@oss.sgi.com Fri Oct 4 11:20:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 11:20:17 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94IKBtG004390 for ; Fri, 4 Oct 2002 11:20:12 -0700 Received: (qmail 21179 invoked by uid 500); 4 Oct 2002 18:19:46 -0000 Subject: Re: Error messages with 2.4.19-aa1 From: Austin Gonyou To: Seth Mos Cc: Stephen Lord , Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021004084834.0376fbb0@pop.xs4all.nl> References: <4.3.2.7.2.20021004084834.0376fbb0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033755586.20542.7.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 04 Oct 2002 13:19:46 -0500 X-archive-position: 799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 01:51, Seth Mos wrote: > At 19:09 3-10-2002 -0500, Austin Gonyou wrote: > >True..and we're using TIGON3 NICs (bcm5700 based stuff). > > I managed to crash a box with the bcm5700 driver. I am asuming you are > using a 2.0 base driver? Hrmm...Ok..I will take a look. I dunno what version is in the 2.4.19 kernel. I know it's minimally broken though. What kind of crash was it?(needed fs checking and all that?) > Get the 2.2 bcm5700 driver or the tg3 driver. Both are a lot better > then > the previous. tg3 is in 2.4.19 already and the bcm5700 driver might be > found on a site like dell support. Hrmm..I'm using the tg3 driver that's in 2.4.19. but it is a bit broken, and imho, could be causing some adjitation(sp?) of things under the right circumstances.i.e. it doesn't report it's TX and RX bytes beyond 4GB. (QLA2300 from 5.38.9 is nearly 1MB when I look at LSMOD!!!) We were in fact, using 6.0b27 during our uptime test, with no issues regarding crashing, which again makes me think it's the QLA driver, but I don't have much to go on, so I'm hunting down every possible avenue I can. :) > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 4 11:22:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 11:22:35 -0700 (PDT) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94IMXtG004603 for ; Fri, 4 Oct 2002 11:22:33 -0700 Received: from there ([216.153.33.187]) by webcube3.volstate.net (8.11.6/8.11.6) with SMTP id g94IMTU04260; Fri, 4 Oct 2002 14:22:29 -0400 Message-Id: <200210041822.g94IMTU04260@webcube3.volstate.net> Content-Type: text/plain; charset="iso-8859-1" From: Joe Bacom Reply-To: joebacom@volstate.net To: Steve Lord Subject: Re: Journal Free Space Date: Fri, 4 Oct 2002 13:21:49 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-xfs@oss.sgi.com References: <200210041458.g94Ewlp22815@webcube3.volstate.net> <1033750143.6896.26.camel@jen.americas.sgi.com> In-Reply-To: <1033750143.6896.26.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Thanks Steve; That solves that question. Now for the next one which was my real intent (I was just using the wrong terminology). Setup: xfs partition that is 3G in size using 4K block size external log on a different partition that is 1G in size, again using 4K blocks. When I created this partition with the external log, I used the maximum log size that mkfs.xfs would allow (-l logdev=/dev/hdc1,size=32768b) As I said in my earlier message, I make extensive use of extended attributes and I need to monitor how much metadata I have stored on disk. I have gone through the man page and online help of xfs_db, and I have to admin some of information is above my knowledge level, but I have not been able to discover anything for what I am looking for. Basically: how much metadata (in bytes, kb, or mb) do I have sitting on the disk. Is there such a command or sequence of commands? Thanks; Joe On Friday 04 October 2002 11:49 am, Steve Lord wrote: > On Fri, 2002-10-04 at 07:56, Joe Bacom wrote: > > Hi Folks; > > > > Hopefully this is an easy question. I would like to know how to > > determine the amount of usage / free space that is left in the journal. > > I have several filesytems that make heavy use of extended attributes, so > > I would like to monitor the journal space to ensure that I don't try to > > overfill it. > > Sending this out since folks are getting confused.... > > The xfs journal (or log, it is called log in the code), is basically > a circular on disk buffer. Metadata changes are recorded into the log, > and subsequently the real metadata is flushed to disk. The benefits of > having a log is we write all the changes which make the filesystem > move from one consistent state to another out into the log in one > go rather than having to sync up several writes to different parts > of the disk. Those writes out to the real metadata happen later, but > we do not care at all about the order they happen in. > > So we perform some transactions, these are written to the log, and > our location in the log keeps moving, eventually wrapping around. > Normally before we wrap the metadata modified in a transaction has > been flushed to disk, so we can just reuse the space. If we are > modifying the filesystem faster than metadata can be flushed to > disk then new operations which need log space have to force the > old metadata out to disk first. > > So you cannot 'run out' of log space, but you can get into the > mode we call tail pushing where the head of the log is always > bumping into the tail. > > Steve From owner-linux-xfs@oss.sgi.com Fri Oct 4 11:50:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 11:50:19 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94IoCtG005580 for ; Fri, 4 Oct 2002 11:50:12 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g94Io7RU022937; Fri, 4 Oct 2002 20:50:07 +0200 (CEST) Message-Id: <4.3.2.7.2.20021004204352.03c875b8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Oct 2002 20:48:51 +0200 To: Austin Gonyou From: Seth Mos Subject: Re: Error messages with 2.4.19-aa1 Cc: Stephen Lord , Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <1033755586.20542.7.camel@UberGeek.coremetrics.com> References: <4.3.2.7.2.20021004084834.0376fbb0@pop.xs4all.nl> <4.3.2.7.2.20021004084834.0376fbb0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 13:19 4-10-2002 -0500, Austin Gonyou wrote: >On Fri, 2002-10-04 at 01:51, Seth Mos wrote: > > At 19:09 3-10-2002 -0500, Austin Gonyou wrote: > > >True..and we're using TIGON3 NICs (bcm5700 based stuff). > > > > I managed to crash a box with the bcm5700 driver. I am asuming you are > > using a 2.0 base driver? > >Hrmm...Ok..I will take a look. I dunno what version is in the 2.4.19 >kernel. I know it's minimally broken though. What kind of crash was >it?(needed fs checking and all that?) Yes, and since the box oopsed there was some slight damage. The corrupt log kind of damaged. We were too late in noticing (it was causing 10 second network stalls) and rebooting the box before it died. >Hrmm..I'm using the tg3 driver that's in 2.4.19. but it is a bit broken, >and imho, could be causing some adjitation(sp?) of things under the >right circumstances.i.e. it doesn't report it's TX and RX bytes beyond >4GB. (QLA2300 from 5.38.9 is nearly 1MB when I look at LSMOD!!!) The 4Gb limit affects all cards. Use snmp if you want to count something. That's what it's ment for anyways. Driver can be quite large yes. Although I remember a xfs module of 12MB as well that had all symbols compiled in :-) >We were in fact, using 6.0b27 during our uptime test, with no issues >regarding crashing, which again makes me think it's the QLA driver, but >I don't have much to go on, so I'm hunting down every possible avenue I >can. :) I have seen some reports and troubles with people and the Qlogic cards. So that is one of the biggest pointers yes. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Oct 4 12:16:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 12:16:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94JGYtG006319 for ; Fri, 4 Oct 2002 12:16:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA09889; Fri, 4 Oct 2002 14:16:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA03111; Fri, 4 Oct 2002 14:16:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94JFdP16879; Fri, 4 Oct 2002 14:15:39 -0500 Subject: Re: Journal Free Space From: Steve Lord To: joebacom@volstate.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210041822.g94IMTU04260@webcube3.volstate.net> References: <200210041458.g94Ewlp22815@webcube3.volstate.net> <1033750143.6896.26.camel@jen.americas.sgi.com> <200210041822.g94IMTU04260@webcube3.volstate.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Oct 2002 14:15:39 -0500 Message-Id: <1033758939.6896.44.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 13:21, Joe Bacom wrote: > Thanks Steve; That solves that question. Now for the next one which was my > real intent (I was just using the wrong terminology). > > Setup: > xfs partition that is 3G in size using 4K block size > external log on a different partition that is 1G in size, again using 4K > blocks. > When I created this partition with the external log, I used the maximum log > size that mkfs.xfs would allow (-l logdev=/dev/hdc1,size=32768b) > > As I said in my earlier message, I make extensive use of extended attributes > and I need to monitor how much metadata I have stored on disk. > > I have gone through the man page and online help of xfs_db, and I have to > admin some of information is above my knowledge level, but I have not been > able to discover anything for what I am looking for. > > Basically: how much metadata (in bytes, kb, or mb) do I have sitting on the > disk. > > Is there such a command or sequence of commands? Well, you can count all the data blocks used by files, and then subtract that from the total blocks used in df output. Not a pleasant prospect. You can look at the frag and freesp commands in xfs_db, but they do not do what you want exactly either. The frag command will tell you how many fragments of directory and attribute metadata you have, but that does not say how many blocks there actually are. xfs_db: frag -d (directories, not data) actual 259, ideal 163, fragmentation factor 37.07% xfs_db: frag -f (this is data) actual 3816, ideal 3806, fragmentation factor 0.26% xfs_db: frag -a actual 0, ideal 0, fragmentation factor 0.00% xfs_db: freesp from to extents blocks pct 1 1 57 57 0.03 2 3 25 62 0.03 4 7 16 78 0.04 8 15 13 144 0.07 16 31 7 170 0.08 32 63 6 334 0.15 64 127 7 613 0.28 128 255 4 763 0.35 256 511 2 697 0.32 512 1023 2 1437 0.66 1024 2047 2 2624 1.20 16384 32767 8 211014 96.80 You can make xfs_db report the type of all blocks in the fs, but it is somewhat verbose. block 0 (0/0) type sb block 1 (0/1) type btino block 2 (0/2) type btbno block 3 (0/3) type btcnt block 4 (0/4) type freelist block 5 (0/5) type freelist block 6 (0/6) type freelist block 7 (0/7) type freelist block 8 (0/8) type inode block 9 (0/9) type inode block 10 (0/10) type inode block 11 (0/11) type inode block 12 (0/12) type dir inode 133 block 13 (0/13) type dir inode 147 block 14 (0/14) type inode block 15 (0/15) type inode Steve > > Thanks; > > Joe > > On Friday 04 October 2002 11:49 am, Steve Lord wrote: > > On Fri, 2002-10-04 at 07:56, Joe Bacom wrote: > > > Hi Folks; > > > > > > Hopefully this is an easy question. I would like to know how to > > > determine the amount of usage / free space that is left in the journal. > > > I have several filesytems that make heavy use of extended attributes, so > > > I would like to monitor the journal space to ensure that I don't try to > > > overfill it. > > > > Sending this out since folks are getting confused.... > > > > The xfs journal (or log, it is called log in the code), is basically > > a circular on disk buffer. Metadata changes are recorded into the log, > > and subsequently the real metadata is flushed to disk. The benefits of > > having a log is we write all the changes which make the filesystem > > move from one consistent state to another out into the log in one > > go rather than having to sync up several writes to different parts > > of the disk. Those writes out to the real metadata happen later, but > > we do not care at all about the order they happen in. > > > > So we perform some transactions, these are written to the log, and > > our location in the log keeps moving, eventually wrapping around. > > Normally before we wrap the metadata modified in a transaction has > > been flushed to disk, so we can just reuse the space. If we are > > modifying the filesystem faster than metadata can be flushed to > > disk then new operations which need log space have to force the > > old metadata out to disk first. > > > > So you cannot 'run out' of log space, but you can get into the > > mode we call tail pushing where the head of the log is always > > bumping into the tail. > > > > Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 4 12:35:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 12:35:51 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94JZjtG006962 for ; Fri, 4 Oct 2002 12:35:45 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA96029 for ; Fri, 4 Oct 2002 14:35:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA61294 for ; Fri, 4 Oct 2002 14:35:39 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94JYv917326; Fri, 4 Oct 2002 14:34:57 -0500 Message-Id: <200210041934.g94JYv917326@jen.americas.sgi.com> Date: Fri, 4 Oct 2002 14:34:57 -0500 Subject: TAKE - fix assert in 2.5 pagebuf code To: linux-xfs@oss.sgi.com X-archive-position: 803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fix 2.5 specific code for small block size filesystems, there was a case where a page sized block filesystem went down to the small blocksize code path. Date: Fri Oct 4 12:35:07 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:129109a linux/fs/xfs/pagebuf/page_buf.c - 1.64 - if the lookup_pages path, do not descend into using page->private for a bitmask for the page sized filesystem blocksize case. From owner-linux-xfs@oss.sgi.com Fri Oct 4 12:44:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 12:44:44 -0700 (PDT) Received: from antigonus.hosting.pacbell.net (antigonus.hosting.pacbell.net [216.100.98.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94JiftG007590 for ; Fri, 4 Oct 2002 12:44:41 -0700 Received: from unminc.com (66-126-254-34.ded.pacbell.net [66.126.254.34]) by antigonus.hosting.pacbell.net id PAA08222; Fri, 4 Oct 2002 15:44:38 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <3D9DEFA0.4080508@unminc.com> Date: Fri, 04 Oct 2002 12:44:32 -0700 From: Curtis Anderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: joebacom@volstate.net, linux-xfs@oss.sgi.com Subject: Re: Journal Free Space References: <200210041458.g94Ewlp22815@webcube3.volstate.net> <1033750143.6896.26.camel@jen.americas.sgi.com> <200210041822.g94IMTU04260@webcube3.volstate.net> <1033758939.6896.44.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: curtis@unminc.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > On Fri, 2002-10-04 at 13:21, Joe Bacom wrote: > > As I said in my earlier message, I make extensive use of extended attributes > > and I need to monitor how much metadata I have stored on disk. [snip] > > Basically: how much metadata (in bytes, kb, or mb) do I have sitting on the > > disk. Here's two more approaches, they are slow in that they are per-file operations, but they will give you the data I think you're looking for. If you want filesystem totals, then the techniques Steve gave are probably better than this (certainly faster). Assuming that the data files you are working with do not have holes (ie: not sparse), you can use this on each file: (stat.st_blocks - (stat.st_size/512)) That number will include all the metadata associated with a file, not just the extended attributes, but it will be close. If the data files have holes, the operation to list the attributes of a file will give you the size (in bytes) of each attribute. Adding those numbers will not include the extra bytes needed to store those attributes, but it will get you close. You can even cache the results by creating a new attribute that contains a timestamp and the total size. If I remember correctly, doing any mods to attributes updates the "ctime" for the inode, so you should be able to compare that timestamp against the "ctime" of the inode and only recalculate if the attributes have changed. I hope this helps... Thanks, Curtis -- Curtis Anderson Dir. of S/W and Dev. curtis@unm.net From owner-linux-xfs@oss.sgi.com Fri Oct 4 13:36:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 13:36:33 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94KaStG008488 for ; Fri, 4 Oct 2002 13:36:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA20136 for ; Fri, 4 Oct 2002 15:36:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA74986 for ; Fri, 4 Oct 2002 15:36:23 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g94KYmj01700; Fri, 4 Oct 2002 15:34:48 -0500 Message-Id: <200210042034.g94KYmj01700@stout.americas.sgi.com> Date: Fri, 4 Oct 2002 15:34:48 -0500 Subject: TAKE - Add missing newlines to cmn_err messages. X-archive-position: 805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS prints lots of info via it's "cmn_err()" function, and the strings passed to it never have newlines. It translates these to printk's but that translation was missing the added newline in some cases. Add missing newlines to cmn_err messages. Date: Fri Oct 4 13:35:05 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129117a linux/fs/xfs/support/debug.c - 1.10 - Add missing newlines to cmn_err messages. From owner-linux-xfs@oss.sgi.com Fri Oct 4 14:15:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 14:15:26 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94LFNtG009307 for ; Fri, 4 Oct 2002 14:15:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA46506 for ; Fri, 4 Oct 2002 16:15:18 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA60834 for ; Fri, 4 Oct 2002 16:15:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g94LDhE02621; Fri, 4 Oct 2002 16:13:43 -0500 Message-Id: <200210042113.g94LDhE02621@stout.americas.sgi.com> Date: Fri, 4 Oct 2002 16:13:43 -0500 Subject: TAKE - Rearrange how xfs deals with read-only mounts vs. read-only devices. X-archive-position: 806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS had several places where it detected a read-only mount, and twiddled the VFS readonly flags before proceeding, for instance with recovery, quotacheck, and quota inode creation. However, the vfs flag is really not what matters here, it's the read-only status of the underlying devices. So, check -that- before attempting to recover, quotacheck, etc, and fail if the device is read-only (this part is no different from previous behavior). The writes we need to do are under the vfs, so the vfs flag really doesn't matter. I also took out warnings pertaining to this behavior, if it's standard behavior, why issue a warning... Also, what may be a real bugfix here, is that xfs would clear out "stale" log blocks from a previous partial log write prior to log recovery, but we were incorrectly skipping that step on read-only mounts. This may have led to some recovery problems, particularly on root devices. Now we skip that skip that step only if the log device itself is read-only, since we can't recover anyway. Rearrange how xfs deals with read-only mounts vs. read-only devices. Date: Fri Oct 4 14:09:39 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129120a linux/fs/xfs/xfs_log_recover.c - 1.243 - Check device for read-only (rather than mount flag) before doing xlog_clear_stale_blocks(). We were skipping this on read-only mounts, which was not a good thing. Don't change VFS readonly flag to do recovery, only check for ro status of underlying device. linux/fs/xfs/xfs_mount.c - 1.303 - Use new xfs_dev_is_read_only function to check device status before changing quota state. Don't change VFS readonly flag to do quotacheck, only check for ro status of underlying device. linux/fs/xfs/xfs_qm.c - 1.86 - Don't change VFS readonly flag to do quotacheck, only check for ro status of underlying device. linux/fs/xfs/linux/xfs_lrw.h - 1.27 linux/fs/xfs/linux/xfs_lrw.c - 1.169 - Remove the vfs read-only checks for various xfs operations, just check whether the underlying device is read-only in a generic way. From owner-linux-xfs@oss.sgi.com Fri Oct 4 14:47:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 14:47:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94LlatG009957 for ; Fri, 4 Oct 2002 14:47:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA40531 for ; Fri, 4 Oct 2002 16:47:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA00538 for ; Fri, 4 Oct 2002 16:47:30 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94LklY18860; Fri, 4 Oct 2002 16:46:47 -0500 Message-Id: <200210042146.g94LklY18860@jen.americas.sgi.com> Date: Fri, 4 Oct 2002 16:46:47 -0500 Subject: TAKE - 2.5 I/O path work To: linux-xfs@oss.sgi.com X-archive-position: 807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs simplify the xfs flush and flush invalidate calls down the what the rest of the kernel uses. Date: Fri Oct 4 14:46:51 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:129128a linux/fs/xfs/linux/xfs_fs_subr.c - 1.37 - one less fdatawait is needed here. From owner-linux-xfs@oss.sgi.com Fri Oct 4 14:49:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 14:49:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94LnatG010124 for ; Fri, 4 Oct 2002 14:49:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60670 for ; Fri, 4 Oct 2002 16:49:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA30692 for ; Fri, 4 Oct 2002 16:49:30 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g94Lml618922; Fri, 4 Oct 2002 16:48:47 -0500 Message-Id: <200210042148.g94Lml618922@jen.americas.sgi.com> Date: Fri, 4 Oct 2002 16:48:47 -0500 Subject: TAKE - fix O_DIRECT cache issue. To: linux-xfs@oss.sgi.com X-archive-position: 808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs O_DIRECT fixup, pending patch from Andrew Morton, removes the case where we tossed cached data but never flushed it. This has been submitted to Linus already. Date: Fri Oct 4 14:48:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:129129a linux/fs/direct-io.c - 1.8 - move the cache flush upto the same level as the cache invalidate in the O_DIRECT path. From owner-linux-xfs@oss.sgi.com Fri Oct 4 15:08:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 15:08:25 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94M8NtG011146 for ; Fri, 4 Oct 2002 15:08:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA65103 for ; Fri, 4 Oct 2002 17:08:17 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA19180 for ; Fri, 4 Oct 2002 17:08:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g94M6gV07146; Fri, 4 Oct 2002 17:06:42 -0500 Message-Id: <200210042206.g94M6gV07146@stout.americas.sgi.com> Date: Fri, 4 Oct 2002 17:06:42 -0500 Subject: TAKE - Fix sysctl values, add PB_CLEAR_OWNER debugging line X-archive-position: 809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This should get pagebuf debugging again I think... Fix sysctl values, add PB_CLEAR_OWNER debugging line Date: Fri Oct 4 15:07:48 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129132a linux/fs/xfs/pagebuf/page_buf.c - 1.65 - Fix sysctl values, add PB_CLEAR_OWNER debugging line From owner-linux-xfs@oss.sgi.com Fri Oct 4 18:22:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 18:22:11 -0700 (PDT) Received: from rose.org.uk ([195.137.41.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g951M4tG017764 for ; Fri, 4 Oct 2002 18:22:05 -0700 Received: from horace.rose.org.uk (horace.rose.org.uk [10.0.0.2]) by rose.org.uk (Postfix) with ESMTP id 1482AB093; Sat, 5 Oct 2002 02:21:59 +0100 (BST) Received: from mat by horace.rose.org.uk with local (Exim 3.36 #1 (Debian)) id 17xddj-0007Ty-00; Sat, 05 Oct 2002 02:21:55 +0100 Date: Sat, 5 Oct 2002 02:21:55 +0100 From: Matthew Rose To: linux-xfs@oss.sgi.com Cc: Tim Shimmin Subject: Re: xfsrestore bus error Message-ID: <20021005012155.GC19227@horace.rose> References: <20021003142456.GA1566@horace.rose> <20021004132705.C399585@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021004132705.C399585@boing.melbourne.sgi.com> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g951M6tG017766 X-archive-position: 810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mat@rose.org.uk Precedence: bulk X-list: linux-xfs I created a small volume for testing and ran the simplest dump/restore I could think of: $ mkfs -t xfs -f /dev/homerdata/testvol $ mount /dev/homerdata/testvol /mnt/xfstest/ $ touch /mnt/xfstest/test $ xfsdump -J -v 5 - /mnt/xfstest 2>dumperr| xfsrestore -J -v 5 - \ /mnt/pub/Backups/restore_test/ > restoreout Bus error This is the stock 2.4.18 with the xfs-1.1-2.4.18-all.patch applied. Both the source and target are on lvm. I'm using xfsdump-2.0.1 and xfsprogs-2.0.3. Here is the dump output (227 lines): xfsdump: RLIMIT_AS org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_STACK org cur 0x800000 max 0x7fffffffffffffff xfsdump: raising stack size soft limit from 0x800000 to 0x2000000 xfsdump: RLIMIT_STACK new cur 0x2000000 max 0x7fffffffffffffff xfsdump: RLIMIT_DATA org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_FSIZE org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_FSIZE now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_CPU cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: RLIMIT_CPU now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsdump: INTGENMAX == 2147483647 (0x7fffffff) xfsdump: UINTGENMAX == 4294967295 (0xffffffff) xfsdump: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: OFFMAX == -1 (0x7fffffff) xfsdump: SIZEMAX == 4294967295 (0xffffffff) xfsdump: INOMAX == 4294967295 (0xffffffff) xfsdump: TIMEMAX == 2147483647 (0x7fffffff) xfsdump: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsdump: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsdump: UINT32MAX == 4294967295 (0xffffffff) xfsdump: INT32MAX == 2147483647 (0x7fffffff) xfsdump: INT16MAX == 32767 (0x7fff) xfsdump: UINT16MAX == 65535 (0xffff) xfsdump: getpagesize( ) returns 4096 xfsdump: parent pid is 6822 xfsdump: effective user id is 0 xfsdump: using file dump (drive_simple) strategy xfsdump: NOTE: pipeline detected xfsdump: version 3.0 - Running single-threaded xfsdump: fs /mnt/xfstest uuid [58b4351b-5533-4d3d-948a-09f783d153c0] xfsdump: creating directory /var/lib/xfsdump xfsdump: level 0 dump of homer:/mnt/xfstest xfsdump: dump date: Sat Oct 5 01:55:18 2002 xfsdump: session id: 48fa0dc3-f673-47f6-aab8-7f23a6e265fe xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: bulkstat iteration initiated: start_ino == 0 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 2 ino 128 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 0 xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: bulkstat iteration initiated: start_ino == 0 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 2 ino 128 xfsdump: inomap_state backed up 0 times xfsdump: ino map construction complete xfsdump: estimated dump size: 21120 bytes xfsdump: estimated dump header size: 20544 bytes xfsdump: estimated component sizes: global hdr: 70368744181760 bytes, inomap: 274877906944 bytes, dir entries: 2473901162496 bytes, file hdrs: 0 bytes, datasz: 578317539679928320 bytes xfsdump: Media op: begin media file xfsdump: drive_simple begin_write( ) xfsdump: xlate_global_hdr: pre-xlate gh_magic xFSdump0 gh_version 2 gh_checksum 0 gh_timestamp 1033779318 gh_ipaddr 655616 gh_hostname homer gh_dumplabel xfsdump: xlate_global_hdr: post-xlate gh_magic xFSdump0 gh_version 33554432 gh_checksum 0 gh_timestamp 1983422013 gh_ipaddr 292470092988416 gh_hostname homer gh_dumplabel xfsdump: xlate_drive_hdr: pre-xlate dh_drivecnt 1 dh_driveix 0 dh_strategyid 1 dh_pad1 dh_specific dh_upper xfsdump: xlate_drive_hdr: post-xlate dh_drivecnt 16777216 dh_driveix 0 dh_strategyid 16777216 dh_pad1 dh_specific dh_upper xfsdump: xlate_media_hdr xfsdump: xlate_content_hdr xfsdump: xlate_content_inode_hdr xfsdump: xlate_startpt xfsdump: xlate_startpt xfsdump: do_begin_write: global_hdr gh_magic xFSdump0 gh_version 33554432 gh_checksum 880798814 gh_timestamp 1983422013 gh_ipaddr 292470092988416 gh_hostname homer gh_dumplabel xfsdump: media file header checksum OK! xfsdump: drive_simple get_write_buf( want 4096 ) xfsdump: drive_simple write( offset 0 (0x0 00) size 4096 (0x1000 010000) ) xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: pre - xlate_hnk xfsdump: post - xlate_hnk xfsdump: drive_simple get_write_buf( want 16384 ) xfsdump: drive_simple write( offset 4096 (0x1000 010000) size 16384 (0x4000 040000) ) xfsdump: dumping directories xfsdump: dump_dirs SGI_FS_BULKSTAT 0 buf len 4096 xfsdump: dump_dirs SGI_FS_BULKSTAT returns 2 entries xfsdump: dumping directory ino 128 xfsdump: xlate_bstat xfsdump: xlate_bstat: pre-xlate bs_ino 128 bs_mode 40755 xfsdump: xlate_bstat: post-xlate bs_ino 9223372036854775808 bs_mode 35520200000 xfsdump: xlate_filehdr: pre-xlate fh_offset 0 fh_flags 0 fh_checksum 577790335665567676 xfsdump: xlate_filehdr: post-xlate fh_offset 0 fh_flags 0 fh_checksum 578394647227793520 xfsdump: drive_simple get_write_buf( want 256 ) xfsdump: drive_simple write( offset 20480 (0x5000 050000) size 256 (0x100 0400) ) xfsdump: xlate_direnthdr: pre-xlate dh_ino 131 dh_gen 0 dh_sz 24 dh_checksum 0 dh_name test xfsdump: xlate_direnthdr: post-xlate dh_ino 9439544818968559616 dh_gen 0 dh_sz 6144 dh_checksum 0 dh_name test xfsdump: drive_simple get_write_buf( want 24 ) xfsdump: drive_simple write( offset 20736 (0x5100 050400) size 24 (0x18 030) ) xfsdump: xlate_direnthdr: pre-xlate dh_ino 0 dh_gen 0 dh_sz 24 dh_checksum 0 dh_name xfsdump: xlate_direnthdr: post-xlate dh_ino 0 dh_gen 0 dh_sz 6144 dh_checksum 0 dh_name xfsdump: drive_simple get_write_buf( want 24 ) xfsdump: drive_simple write( offset 20760 (0x5118 050430) size 24 (0x18 030) ) xfsdump: dump_dirs SGI_FS_BULKSTAT 1 buf len 4096 xfsdump: dump_dirs SGI_FS_BULKSTAT returns 0 entries xfsdump: dumping non-directory files xfsdump: bulkstat iteration initiated: start_ino == 131 xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 1 ino 131 xfsdump: dumping regular file ino 131 offset 0 to offset 0 (size 0) xfsdump: setting media mark for ino 131 offset 0 xfsdump: drive_simple set_mark( ) xfsdump: re-writing media file header with first mark (in buffer) xfsdump: dumping extent group ino 131 offset 0 xfsdump: xlate_bstat xfsdump: xlate_bstat: pre-xlate bs_ino 131 bs_mode 100644 xfsdump: xlate_bstat: post-xlate bs_ino 9439544818968559616 bs_mode 24440200000 xfsdump: xlate_filehdr: pre-xlate fh_offset 0 fh_flags 0 fh_checksum 577790335665543052 xfsdump: xlate_filehdr: post-xlate fh_offset 0 fh_flags 0 fh_checksum 578394647227793520 xfsdump: drive_simple get_write_buf( want 256 ) xfsdump: drive_simple write( offset 20784 (0x5130 050460) size 256 (0x100 0400) ) xfsdump: dumped to end of file xfsdump: dumping extent type = LAST offset = 0 size = 0 xfsdump: xlate_extenthdr xfsdump: drive_simple get_write_buf( want 32 ) xfsdump: drive_simple write( offset 21040 (0x5230 051060) size 32 (0x20 040) ) xfsdump: calling bulkstat xfsdump: bulkstat returns buflen 0 xfsdump: setting media END mark xfsdump: drive_simple set_mark( ) xfsdump: xlate_bstat xfsdump: xlate_bstat: pre-xlate bs_ino 0 bs_mode 0 xfsdump: xlate_bstat: post-xlate bs_ino 0 bs_mode 0 xfsdump: xlate_filehdr: pre-xlate fh_offset 0 fh_flags 5 fh_checksum 577790335665567964 xfsdump: xlate_filehdr: post-xlate fh_offset 0 fh_flags 83886080 fh_checksum 4614221346212151408 xfsdump: drive_simple get_write_buf( want 256 ) xfsdump: drive_simple write( offset 21072 (0x5250 051120) size 256 (0x100 0400) ) xfsdump: setting media NULL mark xfsdump: drive_simple set_mark( ) xfsdump: ending media file xfsdump: Media op: end media file xfsdump: drive_simple end_write( ) xfsdump: flushing write buf addr 0x40144000 size 0x5350 xfsdump: media mark committed for ino 131 offset 0 in media file 0 xfsdump: media END mark committed in media file 0 xfsdump: media NULL mark committed in media file 0 xfsdump: media file size 21328 bytes xfsdump: ending stream: 0 seconds elapsed xfsdump: content.c: 2716: mlog_exit called: exit_code: SUCCESS return: OK (success) xfsdump: dump size (non-dir files) : 0 bytes xfsdump: dump complete: 0 seconds elapsed xfsdump: main.c: 630: mlog_exit called: exit_code: SUCCESS return: OK (success) xfsdump: Dump Status: SUCCESS Here is the restore output (245 lines): xfsrestore: RLIMIT_AS org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: RLIMIT_STACK org cur 0x800000 max 0x7fffffffffffffff xfsrestore: raising stack size soft limit from 0x800000 to 0x2000000 xfsrestore: RLIMIT_STACK new cur 0x2000000 max 0x7fffffffffffffff xfsrestore: RLIMIT_DATA org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: RLIMIT_FSIZE org cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: RLIMIT_FSIZE now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: RLIMIT_CPU cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: RLIMIT_CPU now cur 0x7fffffffffffffff max 0x7fffffffffffffff xfsrestore: INTGENMAX == 2147483647 (0x7fffffff) xfsrestore: UINTGENMAX == 4294967295 (0xffffffff) xfsrestore: OFF64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: OFFMAX == -1 (0x7fffffff) xfsrestore: SIZEMAX == 4294967295 (0xffffffff) xfsrestore: INOMAX == 4294967295 (0xffffffff) xfsrestore: TIMEMAX == 2147483647 (0x7fffffff) xfsrestore: SIZE64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INO64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: UINT64MAX == 18446744073709551615 (0xffffffffffffffff) xfsrestore: INT64MAX == 9223372036854775807 (0x7fffffffffffffff) xfsrestore: UINT32MAX == 4294967295 (0xffffffff) xfsrestore: INT32MAX == 2147483647 (0x7fffffff) xfsrestore: INT16MAX == 32767 (0x7fff) xfsrestore: UINT16MAX == 65535 (0xffff) xfsrestore: getpagesize( ) returns 4096 xfsrestore: parent pid is 6823 xfsrestore: using file dump (drive_simple) strategy xfsrestore: NOTE: pipeline detected xfsrestore: tty fd: 3; terminal interrupt character:  (03) xfsrestore: version 3.0 - Running single-threaded xfsrestore: sizeof( pers_desc_t ) == 328, pgsz == 4096, perssz == 20480 ::::::::::: persistent inventory media file tree at initialization ::::::::::: session inventory unknown ...................... end persistent inventory display ...................... xfsrestore: Media_create xfsrestore: checking and validating command line dump id/label xfsrestore: searching media for dump xfsrestore: Media_mfile_next: purp==0 pos==0 xfsrestore: drive_simple begin_read( ) xfsrestore: drive_simple read( want 4096 ) xfsrestore: drive_simple return_read_buf( returning 4096 ) xfsrestore: do_begin_read: global_hdr gh_magic xFSdump0 gh_version 33554432 gh_checksum 70184030 gh_timestamp 1983422013 gh_ipaddr 292470092988416 gh_hostname homer gh_dumplabel xfsrestore: xlate_global_hdr: pre-xlate gh_magic xFSdump0 gh_version 33554432 gh_checksum 70184030 gh_timestamp 1983422013 gh_ipaddr 292470092988416 gh_hostname homer gh_dumplabel xfsrestore: xlate_global_hdr: post-xlate gh_magic xFSdump0 gh_version 2 gh_checksum 1592536580 gh_timestamp 1033779318 gh_ipaddr 655616 gh_hostname homer gh_dumplabel xfsrestore: xlate_drive_hdr: pre-xlate dh_drivecnt 16777216 dh_driveix 0 dh_strategyid 16777216 dh_pad1 dh_specific dh_upper xfsrestore: xlate_drive_hdr: post-xlate dh_drivecnt 1 dh_driveix 0 dh_strategyid 1 dh_pad1 dh_specific dh_upper xfsrestore: xlate_media_hdr xfsrestore: xlate_content_hdr xfsrestore: xlate_content_inode_hdr xfsrestore: xlate_startpt xfsrestore: xlate_startpt xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: dump found: checking xfsrestore: dump description: xfsrestore: hostname: homer xfsrestore: mount point: /mnt/xfstest xfsrestore: volume: /dev/homerdata/testvol xfsrestore: session time: Sat Oct 5 01:55:18 2002 xfsrestore: level: 0 xfsrestore: session label: "" xfsrestore: media label: "" xfsrestore: file system id: 58b4351b-5533-4d3d-948a-09f783d153c0 xfsrestore: session id: 48fa0dc3-f673-47f6-aab8-7f23a6e265fe xfsrestore: media id: 964f0fbb-9781-4dfb-83d6-1a083924d05e :::::::::: persistent inventory media file tree after pi_insertfile :::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 may be additional unidentified media files may be additional unidentified media objects ...................... end persistent inventory display ...................... :::::::::: persistent inventory media file tree after pi_seestrmend :::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 may be additional unidentified media files ...................... end persistent inventory display ...................... :::::::: persistent inventory media file tree after pi_seeobjstrmend ::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 ...................... end persistent inventory display ...................... xfsrestore: searching media for directory dump xfsrestore: Media_mfile_next: purp==1 pos==1 xfsrestore: dump session label: "" xfsrestore: dump session id: 48fa0dc3-f673-47f6-aab8-7f23a6e265fe xfsrestore: stream 0, object 0, file 0 :::::::::: persistent inventory media file tree after pi_insertfile :::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 ...................... end persistent inventory display ...................... :::::::::: persistent inventory media file tree after pi_seestrmend :::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 ...................... end persistent inventory display ...................... :::::::: persistent inventory media file tree after pi_seeobjstrmend ::::::::: session inventory display media stream 0: media object 0: label is blank id: 964f0fbb-9781-4dfb-83d6-1a083924d05e index within object of first media file: 0 index within stream of first media file: 0 media file 0 (0): first extent contained: ino 131 off 0 next extent to restore: ino 131 off 0 rollback mark 0 ...................... end persistent inventory display ...................... xfsrestore: initializing directory attributes registry xfsrestore: content_stream_restore: dircnt 1 xfsrestore: initializing directory entry name registry xfsrestore: initializing directory hierarchy image From owner-linux-xfs@oss.sgi.com Fri Oct 4 18:30:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 18:30:30 -0700 (PDT) Received: from rose.org.uk ([195.137.41.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g951URtG018262 for ; Fri, 4 Oct 2002 18:30:28 -0700 Received: from horace.rose.org.uk (horace.rose.org.uk [10.0.0.2]) by rose.org.uk (Postfix) with ESMTP id 3E5D93D1; Sat, 5 Oct 2002 02:30:22 +0100 (BST) Received: from mat by horace.rose.org.uk with local (Exim 3.36 #1 (Debian)) id 17xdlq-0007dn-00; Sat, 05 Oct 2002 02:30:18 +0100 Date: Sat, 5 Oct 2002 02:30:18 +0100 From: Matthew Rose To: linux-xfs@oss.sgi.com Cc: Tim Shimmin Subject: Re: xfsrestore bus error Message-ID: <20021005013018.GA28934@horace.rose> References: <20021003142456.GA1566@horace.rose> <20021004132705.C399585@boing.melbourne.sgi.com> <20021005012155.GC19227@horace.rose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021005012155.GC19227@horace.rose> User-Agent: Mutt/1.4i X-archive-position: 811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mat@rose.org.uk Precedence: bulk X-list: linux-xfs I found the problem: I hadn't recompiled xfsrestore since upgrading libc. Doh. Matt On (05/10/02 02:21), Matthew Rose wrote: > I created a small volume for testing and ran the simplest dump/restore > I could think of: > > $ mkfs -t xfs -f /dev/homerdata/testvol > $ mount /dev/homerdata/testvol /mnt/xfstest/ > $ touch /mnt/xfstest/test > $ xfsdump -J -v 5 - /mnt/xfstest 2>dumperr| xfsrestore -J -v 5 - \ > /mnt/pub/Backups/restore_test/ > restoreout > Bus error > > This is the stock 2.4.18 with the xfs-1.1-2.4.18-all.patch applied. > Both the source and target are on lvm. > I'm using xfsdump-2.0.1 and xfsprogs-2.0.3. > > > Here is the dump output (227 lines): From owner-linux-xfs@oss.sgi.com Fri Oct 4 18:49:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 18:49:12 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g951n8tG018803 for ; Fri, 4 Oct 2002 18:49:08 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1CF7E1E2B5A; Fri, 4 Oct 2002 18:49:08 -0700 (PDT) Date: Fri, 4 Oct 2002 18:49:08 -0700 From: Chris Wedgwood To: Matthew Rose Cc: linux-xfs@oss.sgi.com, Tim Shimmin Subject: Re: xfsrestore bus error Message-ID: <20021005014908.GA26154@tapu.f00f.org> References: <20021003142456.GA1566@horace.rose> <20021004132705.C399585@boing.melbourne.sgi.com> <20021005012155.GC19227@horace.rose> <20021005013018.GA28934@horace.rose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021005013018.GA28934@horace.rose> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Oct 05, 2002 at 02:30:18AM +0100, Matthew Rose wrote: > I found the problem: I hadn't recompiled xfsrestore since upgrading > libc. Doh. Which version of libc did you have before and what version do you have now? --cw From owner-linux-xfs@oss.sgi.com Fri Oct 4 18:59:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 18:59:02 -0700 (PDT) Received: from rose.org.uk ([195.137.41.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g951wxtG019344 for ; Fri, 4 Oct 2002 18:59:00 -0700 Received: from horace.rose.org.uk (horace.rose.org.uk [10.0.0.2]) by rose.org.uk (Postfix) with ESMTP id C3297ADD6; Sat, 5 Oct 2002 02:58:52 +0100 (BST) Received: from mat by horace.rose.org.uk with local (Exim 3.36 #1 (Debian)) id 17xeDR-0008Fj-00; Sat, 05 Oct 2002 02:58:49 +0100 Date: Sat, 5 Oct 2002 02:58:49 +0100 From: Matthew Rose To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore bus error Message-ID: <20021005015849.GA31098@horace.rose> References: <20021003142456.GA1566@horace.rose> <20021004132705.C399585@boing.melbourne.sgi.com> <20021005012155.GC19227@horace.rose> <20021005013018.GA28934@horace.rose> <20021005014908.GA26154@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021005014908.GA26154@tapu.f00f.org> User-Agent: Mutt/1.4i X-archive-position: 813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mat@rose.org.uk Precedence: bulk X-list: linux-xfs On (04/10/02 18:49), Chris Wedgwood wrote: > On Sat, Oct 05, 2002 at 02:30:18AM +0100, Matthew Rose wrote: > > > I found the problem: I hadn't recompiled xfsrestore since upgrading > > libc. Doh. > > Which version of libc did you have before and what version do you have > now? > I had 2.1.3 (Debian Potato) and now use 2.2.5 (Debian Woody). I assume it was the libc upgrade that did it. A simple recompile of xfsrestore solved the symptoms. -- Matt Rose |Necessity is the plea for every infringement of human freedom. matt@rose.org.uk|It is the argument of tyrants; it is the creed of slaves - Pitt From owner-linux-xfs@oss.sgi.com Fri Oct 4 19:10:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Oct 2002 19:10:37 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g952AZtG019925 for ; Fri, 4 Oct 2002 19:10:35 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 2B7A79469; Fri, 4 Oct 2002 19:10:35 -0700 (PDT) Date: Fri, 4 Oct 2002 19:10:35 -0700 From: Chris Wedgwood To: Matthew Rose Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore bus error Message-ID: <20021005021035.GA26584@tapu.f00f.org> References: <20021003142456.GA1566@horace.rose> <20021004132705.C399585@boing.melbourne.sgi.com> <20021005012155.GC19227@horace.rose> <20021005013018.GA28934@horace.rose> <20021005014908.GA26154@tapu.f00f.org> <20021005015849.GA31098@horace.rose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021005015849.GA31098@horace.rose> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Oct 05, 2002 at 02:58:49AM +0100, Matthew Rose wrote: > I had 2.1.3 (Debian Potato) and now use 2.2.5 (Debian Woody). I > assume it was the libc upgrade that did it. A simple recompile of > xfsrestore solved the symptoms. Could be. FWIW, there are Debian packages for this which have dependencies for the right libc version(s). --cw From owner-linux-xfs@oss.sgi.com Sat Oct 5 09:58:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Oct 2002 09:58:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95GwRtG027945 for ; Sat, 5 Oct 2002 09:58:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA84960 for ; Sat, 5 Oct 2002 11:58:22 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA21689 for ; Sat, 5 Oct 2002 11:58:19 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g95Guar15446; Sat, 5 Oct 2002 11:56:36 -0500 Message-Id: <200210051656.g95Guar15446@stout.americas.sgi.com> Date: Sat, 5 Oct 2002 11:56:36 -0500 Subject: TAKE - Fix up the read-only device test changes X-archive-position: 815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Check rtdev as well when testing for read-only devices Fix device that we check prior to xlog_clear_stale_blocks (2.4 only) Date: Sat Oct 5 09:57:40 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129155a linux/fs/xfs/xfs_log_recover.c - 1.244 - Fix device that we check prior to xlog_clear_stale_blocks (2.4 only) linux/fs/xfs/linux/xfs_lrw.c - 1.170 - Check rtdev as well when testing for read-only devices From owner-linux-xfs@oss.sgi.com Sat Oct 5 11:01:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Oct 2002 11:01:10 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95I17tG030533 for ; Sat, 5 Oct 2002 11:01:07 -0700 Received: from there ([64.170.63.74]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H3I00GJVSPV6P@mta5.snfc21.pbi.net> for linux-xfs@oss.sgi.com; Sat, 05 Oct 2002 11:01:07 -0700 (PDT) Date: Sat, 05 Oct 2002 11:01:07 -0700 From: Ron Smith Subject: Mounting SGI-XFS drives To: linux-xfs@oss.sgi.com Message-id: <0H3I00GJWSPV6P@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit X-archive-position: 816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ronnet@pacbell.net Precedence: bulk X-list: linux-xfs I'm running Mandrake 8.2 and have formatted the system drive and attached RAID as XFS on my Linux system. When I attach an additional external drive that was previously attached to an SGI Octane, I cannot mount the drive. I do not have an sdc1 in the /dev directory. How do I create that device? Also, what else is it that I have to do to read the data on the SGI drive once it is mounted on the Linux box? Ron Smith ronnetron@hotmail.com ronnet@pacbell.net From owner-linux-xfs@oss.sgi.com Sat Oct 5 11:39:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Oct 2002 11:39:13 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95IdAtG031520 for ; Sat, 5 Oct 2002 11:39:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA77230 for ; Sat, 5 Oct 2002 13:39:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA20636 for ; Sat, 5 Oct 2002 13:39:05 -0500 (CDT) Date: Sat, 5 Oct 2002 13:37:00 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ron Smith Subject: Re: Mounting SGI-XFS drives In-Reply-To: <0H3I00GJWSPV6P@mta5.snfc21.pbi.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Sat, 5 Oct 2002 13:37:11 -0500 (CDT) ReSent-From: Eric Sandeen ReSent-To: linux-xfs@oss.sgi.com ReSent-Subject: Re: Mounting SGI-XFS drives ReSent-Message-ID: X-archive-position: 817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Ron - http://oss.sgi.com/projects/xfs/faq.html#useirixdisks is the place to start, if you have further problems let us know... -Eric On Sat, 5 Oct 2002, Ron Smith wrote: > I'm running Mandrake 8.2 and have formatted the system drive and attached > RAID as XFS on my Linux system. When I attach an additional external drive > that was previously attached to an SGI Octane, I cannot mount the drive. I do > not have an sdc1 in the /dev directory. How do I create that device? > > Also, what else is it that I have to do to read the data on the SGI drive > once it is mounted on the Linux box? > > Ron Smith > ronnetron@hotmail.com > ronnet@pacbell.net > > From owner-linux-xfs@oss.sgi.com Sat Oct 5 19:17:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Oct 2002 19:17:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g962H9tG003950 for ; Sat, 5 Oct 2002 19:17:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA71498 for ; Sat, 5 Oct 2002 21:17:03 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA54669 for ; Sat, 5 Oct 2002 21:17:03 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g962FHW19293; Sat, 5 Oct 2002 21:15:17 -0500 Message-Id: <200210060215.g962FHW19293@stout.americas.sgi.com> Date: Sat, 5 Oct 2002 21:15:17 -0500 Subject: TAKE - Fix xfsidbg when buit as module X-archive-position: 818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Somday we'll get Steve to build his modules. :) Export xfs_bmbt_get_all for the last fix in xfsidbg.c Date: Sat Oct 5 19:15:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129160a linux/fs/xfs/linux/xfs_globals.c - 1.35 - Export xfs_bmbt_get_all for the last fix in xfsidbg.c From owner-linux-xfs@oss.sgi.com Sun Oct 6 06:22:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 06:22:40 -0700 (PDT) Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96DMbtG016319 for ; Sun, 6 Oct 2002 06:22:37 -0700 Received: from nwourms@netscape.net by imo-r04.mx.aol.com (mail_out_v34.13.) id 4.1ae.245aa71 (16239) for ; Sun, 6 Oct 2002 09:22:22 -0400 (EDT) Received: from netscape.net ([130.127.122.186]) by air-in03.mx.aol.com (v89.10) with ESMTP id MAILININ33-1006092222; Sun, 06 Oct 2002 09:22:22 -0400 Message-ID: <3DA038BA.9050904@netscape.net> Date: Sun, 06 Oct 2002 09:20:58 -0400 From: Nicholas Wourms User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 MultiZilla/v1.1.22 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [KDB & 2.5.40]: Kai's changes to kbuild (as of today) breaks kdb compile Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) X-archive-position: 819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nwourms@netscape.net Precedence: bulk X-list: linux-xfs Hi, I don't know if folks are aware, but Kai has made some major tweaks to the main Makefile which require reworking the KDB related configury into the Makefile. Not quite sure how to proceed, but I thought I'd see if anyone had any ideas. Kai's message, of course, can be found on the kernel mailing list. Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Sun Oct 6 07:41:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 07:41:21 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96EfDtG017352 for ; Sun, 6 Oct 2002 07:41:14 -0700 Received: (qmail 31606 invoked from network); 6 Oct 2002 14:41:11 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Oct 2002 14:41:11 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 28B453045A6; Mon, 7 Oct 2002 00:40:16 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 007D826E; Mon, 7 Oct 2002 00:40:15 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Nicholas Wourms Cc: linux-xfs@oss.sgi.com Subject: Re: [KDB & 2.5.40]: Kai's changes to kbuild (as of today) breaks kdb compile In-reply-to: Your message of "Sun, 06 Oct 2002 09:20:58 -0400." <3DA038BA.9050904@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 2002 00:40:10 +1000 Message-ID: <31397.1033915210@ocs3.intra.ocs.com.au> X-archive-position: 820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 06 Oct 2002 09:20:58 -0400, Nicholas Wourms wrote: >I don't know if folks are aware, but Kai has made some major >tweaks to the main Makefile which require reworking the KDB >related configury into the Makefile. Wait until 2.5.41 is released. I do not do kdb patches against BK trees. From owner-linux-xfs@oss.sgi.com Sun Oct 6 09:11:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 09:11:09 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96GAxtG018476 for ; Sun, 6 Oct 2002 09:11:00 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g96GAu808635; Sun, 6 Oct 2002 18:10:56 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yDzb-0002zo-00; Sun, 06 Oct 2002 18:10:55 +0200 Date: Sun, 6 Oct 2002 18:10:55 +0200 From: Christian Guggenberger To: nathans@debian.org Cc: linux-xfs@oss.sgi.com Subject: problems with latest xfs-CVS cmd's Message-ID: <20021006181055.A10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 46 X-archive-position: 821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi Nathan, While trying to compile the latest xfs-cmd's packages from today's CVS with debian build scripts, I am running into several Problems. I'm using an uptodate debian/unstable, with bonnie79:/usr/local/src/linux-2.4-xfs/cmd/xfsdump# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) bonnie79:/usr/local/src/linux-2.4-xfs/cmd/xfsdump# ld -v GNU ld version 2.13.90.0.4 20020814 Debian GNU/Linux 1. xfsprogs builds correctly, only the version of the built deb is 2.3.0 instead of 2.3.4 2. xfsdump fails to build: === fsr === /usr/bin/libtool --mode=link gcc -o xfs_fsr xfs_fsr.o /usr/lib/libhandle.la /usr/lib/libattr.la gcc -o xfs_fsr xfs_fsr.o /lib/libhandle.so /lib/libattr.so gcc.real: /lib/libhandle.so: No such file or directory make[2]: *** [xfs_fsr] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/src/linux-2.4-xfs/cmd/xfsdump' make: *** [built] Error 2 3. the attr packages are build, and I can install them with dpkg. But: bonnie79:/usr/local/src/linux-2.4-xfs/cmd# dpkg -i libattr1_2.0.11-1_i386.deb (Reading database ... 118080 files and directories currently installed.) Preparing to replace libattr1 2.0.11-1 (using libattr1_2.0.11-1_i386.deb) ... Unpacking replacement libattr1 ... Setting up libattr1 (2.0.11-1) ... ldconfig: Cannot mmap file /usr/lib/libattr.so. ldconfig: Cannot mmap file /usr/lib/libhandle.so. any hints? Christian From owner-linux-xfs@oss.sgi.com Sun Oct 6 10:04:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 10:04:07 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96H45tG019184 for ; Sun, 6 Oct 2002 10:04:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA45457; Sun, 6 Oct 2002 12:04:00 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA80017; Sun, 6 Oct 2002 12:03:57 -0500 (CDT) Date: Sun, 6 Oct 2002 12:02:06 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Christian Guggenberger cc: nathans@debian.org, Subject: Re: problems with latest xfs-CVS cmd's In-Reply-To: <20021006181055.A10715@pc9391.uni-regensburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs The files you're missing are part of the xfsprogs-devel and attr-devel packages, have you installed those? -Eric On Sun, 6 Oct 2002, Christian Guggenberger wrote: > Hi Nathan, > > While trying to compile the latest xfs-cmd's packages from today's CVS > with debian build scripts, I am running into several Problems. > I'm using an uptodate debian/unstable, with > > bonnie79:/usr/local/src/linux-2.4-xfs/cmd/xfsdump# gcc -v > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs > gcc version 2.95.4 20011002 (Debian prerelease) > > bonnie79:/usr/local/src/linux-2.4-xfs/cmd/xfsdump# ld -v > GNU ld version 2.13.90.0.4 20020814 Debian GNU/Linux > > 1. xfsprogs builds correctly, only the version of the built deb is 2.3.0 > instead of 2.3.4 > > 2. xfsdump fails to build: > > === fsr === > /usr/bin/libtool --mode=link gcc -o xfs_fsr xfs_fsr.o > /usr/lib/libhandle.la /usr/lib/libattr.la gcc -o xfs_fsr xfs_fsr.o > /lib/libhandle.so /lib/libattr.so > gcc.real: /lib/libhandle.so: No such file or directory > make[2]: *** [xfs_fsr] Error 1 > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/usr/local/src/linux-2.4-xfs/cmd/xfsdump' > make: *** [built] Error 2 > > 3. the attr packages are build, and I can install them with dpkg. But: > > bonnie79:/usr/local/src/linux-2.4-xfs/cmd# dpkg -i > libattr1_2.0.11-1_i386.deb (Reading database ... 118080 files and > directories currently installed.) > Preparing to replace libattr1 2.0.11-1 (using libattr1_2.0.11-1_i386.deb) > ... > Unpacking replacement libattr1 ... > Setting up libattr1 (2.0.11-1) ... > ldconfig: Cannot mmap file /usr/lib/libattr.so. > > ldconfig: Cannot mmap file /usr/lib/libhandle.so. > > any hints? > > Christian > > > From owner-linux-xfs@oss.sgi.com Sun Oct 6 10:12:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 10:12:48 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96HChtG019666 for ; Sun, 6 Oct 2002 10:12:43 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g96HCd829009; Sun, 6 Oct 2002 19:12:39 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yExL-0003bA-00; Sun, 06 Oct 2002 19:12:39 +0200 Date: Sun, 6 Oct 2002 19:12:37 +0200 From: Christian Guggenberger To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: problems with latest xfs-CVS cmd's Message-ID: <20021006191237.C10715@pc9391.uni-regensburg.de> References: <20021006181055.A10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from sandeen@sgi.com on Sun, Oct 06, 2002 at 19:02:06 +0200 X-Mailer: Balsa 1.2.4 Lines: 10 X-archive-position: 823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 06 Oct 2002 19:02:06 Eric Sandeen wrote: > The files you're missing are part of the xfsprogs-devel and attr-devel > packages, have you installed those? > > -Eric > yep, attr-dev and xfslibs-dev are installed... Christian From owner-linux-xfs@oss.sgi.com Sun Oct 6 10:32:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 10:33:00 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96HWvtG020270 for ; Sun, 6 Oct 2002 10:32:58 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g96HWr805826; Sun, 6 Oct 2002 19:32:53 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yFGv-0003lR-00; Sun, 06 Oct 2002 19:32:53 +0200 Date: Sun, 6 Oct 2002 19:32:52 +0200 From: Christian Guggenberger To: Eric Sandeen Cc: nathans@debian.org, linux-xfs@oss.sgi.com Subject: Re: problems with latest xfs-CVS cmd's Message-ID: <20021006193252.E10715@pc9391.uni-regensburg.de> References: <20021006181055.A10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from sandeen@sgi.com on Sun, Oct 06, 2002 at 19:02:06 +0200 X-Mailer: Balsa 1.2.4 Lines: 13 X-archive-position: 824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 06 Oct 2002 19:02:06 Eric Sandeen wrote: > The files you're missing are part of the xfsprogs-devel and attr-devel > packages, have you installed those? > > -Eric I just tried to compile on a Debian Woody machine and it worked... The only remaining issues are the version strings of the debs. 2.2.1 instead of 2.2.2 (xfsdump), 2.3.0 instead of 2.3.0 instead of 2.3.4 (xfsprogs). But the problems remain for debian/unstable... Christian From owner-linux-xfs@oss.sgi.com Sun Oct 6 13:00:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 13:00:46 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96K0ctG021652 for ; Sun, 6 Oct 2002 13:00:40 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g96K0X826687; Sun, 6 Oct 2002 22:00:33 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yHZp-0005Bh-00; Sun, 06 Oct 2002 22:00:33 +0200 Date: Sun, 6 Oct 2002 22:00:33 +0200 From: Christian Guggenberger To: Eric Sandeen Cc: nathans@debian.org, linux-xfs@oss.sgi.com Subject: Re: problems with latest xfs-CVS cmd's Message-ID: <20021006220033.G10715@pc9391.uni-regensburg.de> References: <20021006181055.A10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from sandeen@sgi.com on Sun, Oct 06, 2002 at 19:02:06 +0200 X-Mailer: Balsa 1.2.4 Lines: 22 X-archive-position: 825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 06 Oct 2002 19:02:06 Eric Sandeen wrote: > The files you're missing are part of the xfsprogs-devel and attr-devel > packages, have you installed those? > > -Eric > it seems to be really a problem with the debian/unstable distribution. On my system I can't even build proper packages with the original debian attr and xfsprogs sources. look at that: bonnie79:/usr/lib# ls -l libattr.so lrwxr-xr-x 1 root root 1 2002-10-06 21:44 libattr.so -> / bonnie79:/usr/lib# ls -l libhandle.so lrwxr-xr-x 1 root root 1 2002-10-06 21:58 libhandle.so -> / Christian From owner-linux-xfs@oss.sgi.com Sun Oct 6 13:13:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 13:13:25 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96KDMtG022202 for ; Sun, 6 Oct 2002 13:13:22 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 NAA02865 for ; Sun, 6 Oct 2002 13:13:21 -0700 (PDT) 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 GAA27639; Mon, 7 Oct 2002 06:12:04 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id GAA50749; Mon, 7 Oct 2002 06:12:03 +1000 (EST) Date: Mon, 7 Oct 2002 06:12:03 +1000 From: Nathan Scott To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: problems with latest xfs-CVS cmd's Message-ID: <20021007061203.A250170@wobbly.melbourne.sgi.com> References: <20021006181055.A10715@pc9391.uni-regensburg.de> <20021006193252.E10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021006193252.E10715@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Sun, Oct 06, 2002 at 07:32:52PM +0200 X-archive-position: 826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sun, Oct 06, 2002 at 07:32:52PM +0200, Christian Guggenberger wrote: > On 06 Oct 2002 19:02:06 Eric Sandeen wrote: > > The files you're missing are part of the xfsprogs-devel and attr-devel > > packages, have you installed those? > > > > -Eric > > I just tried to compile on a Debian Woody machine and it worked... The > only remaining issues are the version strings of the debs. 2.2.1 instead > of 2.2.2 (xfsdump), 2.3.0 instead of 2.3.0 instead of 2.3.4 (xfsprogs). I only update the debian/changelog version strings just prior to uploading new packages to the Debian archive. If you're building from CVS you will sometimes need to edit this file manually. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 6 13:32:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 13:33:02 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96KWutG023264 for ; Sun, 6 Oct 2002 13:32:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 NAA08860 for ; Sun, 6 Oct 2002 13:32:55 -0700 (PDT) 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 GAA27804; Mon, 7 Oct 2002 06:31:38 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id GAA45147; Mon, 7 Oct 2002 06:31:37 +1000 (EST) Date: Mon, 7 Oct 2002 06:31:36 +1000 From: Nathan Scott To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com Subject: Re: problems with latest xfs-CVS cmd's Message-ID: <20021007063136.B250170@wobbly.melbourne.sgi.com> References: <20021006181055.A10715@pc9391.uni-regensburg.de> <20021006220033.G10715@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021006220033.G10715@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Sun, Oct 06, 2002 at 10:00:33PM +0200 X-archive-position: 827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sun, Oct 06, 2002 at 10:00:33PM +0200, Christian Guggenberger wrote: > On 06 Oct 2002 19:02:06 Eric Sandeen wrote: > > The files you're missing are part of the xfsprogs-devel and attr-devel > > packages, have you installed those? > > > > -Eric > > > > it seems to be really a problem with the debian/unstable distribution. > On my system I can't even build proper packages with the original debian > attr and xfsprogs sources. > > look at that: > > bonnie79:/usr/lib# ls -l libattr.so > lrwxr-xr-x 1 root root 1 2002-10-06 21:44 libattr.so -> / > > bonnie79:/usr/lib# ls -l libhandle.so lrwxr-xr-x 1 root root > 1 2002-10-06 21:58 libhandle.so -> / > Hmm... you seem to have installed something broken in your attempts to roll your own packages - this is not what these symlinks in the packages downloaded from the Debian archives look like... I'm not sure how things managed to get into that state though, you've probably passed bad args to configure somewhere along the way. This is what the current packages in unstable contains: # cat /etc/debian_version testing/unstable # dpkg -r xfslibs-dev (Reading database ... 32624 files and directories currently installed.) Removing xfslibs-dev ... # ls -l /usr/lib/libhandle* ls: No match. # apt-get install xfslibs-dev ... Unpacking xfslibs-dev (from .../xfslibs-dev_2.3.1-1_i386.deb) ... Setting up xfslibs-dev (2.3.1-1) ... # ls -l /usr/lib/libhandle* -rw-r--r-- 1 root root 5314 Sep 5 17:01 /usr/lib/libhandle.a -rw-r--r-- 1 root root 711 Sep 5 17:01 /usr/lib/libhandle.la lrwxr-xr-x 1 root root 17 Oct 7 06:23 /usr/lib/libhandle.so -> /lib/libhandle.so Anyway, I'll upload current versions of packages for unstable later today. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 6 23:02:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 23:02:56 -0700 (PDT) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9762ntG006241 for ; Sun, 6 Oct 2002 23:02:50 -0700 Received: (qmail 44105 invoked from network); 7 Oct 2002 06:02:44 -0000 Received: from 202-6-129-125.ip.adam.com.au (HELO adam.com.au) (202.6.129.125) by eden.adam.com.au with SMTP; 7 Oct 2002 06:02:44 -0000 Message-ID: <3DA126E0.A7821938@adam.com.au> Date: Mon, 07 Oct 2002 15:47:04 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.19-CVS Unable to Mount Root File System Content-Type: multipart/mixed; boundary="------------667E22FE9F331B6D8DD33085" X-archive-position: 828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------667E22FE9F331B6D8DD33085 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a root filesystem that would have been made by the original RedHat 7.1 Installer image. I know, it's old but I don't have a lot of bandwidth. I've managed to get it running with: [lloy0076@linux lloy0076]$ uname -a Linux linux 2.4.18-SGI_XFS_1.1 #1 Wed Apr 17 11:18:22 CDT 2002 i686 unknown [lloy0076@linux lloy0076]$ rpm -qa | grep xfs XFree86-xfs-4.0.3-5 xfsprogs-devel-1.2.0-0 xfsdump-2.0.1-0 xfsprogs-2.0.3-0 However, when I build that Kernel or the 2.4.19-CVS kernel (from about 5 hours ago), I get: "Kernel Panic. VFS unable to mount file system 03:02" "Invalid Magic SB Number" Can anyone suggest what I might do to provide more information about this problem (or if it's an obvious one to everyone but me, what the problem might be caused by)? DSL -- You'll be lost, so sorry when I'm gone! (Jesus Christ, in Lloyd Webber's Superstar) --------------667E22FE9F331B6D8DD33085 Content-Type: text/x-vcard; charset=us-ascii; name="lloy0076.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Lloyd Content-Disposition: attachment; filename="lloy0076.vcf" begin:vcard n:Lloyd;David tel;cell:+61 4 02 44 09 93 tel;home:+61 8 8165 0305 x-mozilla-html:FALSE url:http://www.rebel.net.au/~lloy0076 adr:;;131 St Bernards Road;Rostrevor;South Australia;5073;Australia version:2.1 email;internet:lloy0076@adam.com.au x-mozilla-cpt:;0 fn:David Lloyd end:vcard --------------667E22FE9F331B6D8DD33085-- From owner-linux-xfs@oss.sgi.com Sun Oct 6 23:07:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 23:07:17 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9767CtG006545 for ; Sun, 6 Oct 2002 23:07:15 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 8ED61F6B4; Sun, 6 Oct 2002 23:07:12 -0700 (PDT) Date: Sun, 6 Oct 2002 23:07:12 -0700 From: Chris Wedgwood To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System Message-ID: <20021007060712.GA22104@tapu.f00f.org> References: <3DA126E0.A7821938@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA126E0.A7821938@adam.com.au> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Mon, Oct 07, 2002 at 03:47:04PM +0930, David Lloyd wrote: > [lloy0076@linux lloy0076]$ uname -a > Linux linux 2.4.18-SGI_XFS_1.1 #1 Wed Apr 17 11:18:22 CDT 2002 i686 unknown 'k > "Kernel Panic. VFS unable to mount file system 03:02" > "Invalid Magic SB Number" the root device is /hde/hda2 right? what does "xfs_check /dev/hda2" print? --cw From owner-linux-xfs@oss.sgi.com Sun Oct 6 23:10:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 23:10:57 -0700 (PDT) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g976ArtG006904 for ; Sun, 6 Oct 2002 23:10:54 -0700 Received: (qmail 54205 invoked from network); 7 Oct 2002 06:10:48 -0000 Received: from 202-6-129-125.ip.adam.com.au (HELO adam.com.au) (202.6.129.125) by eden.adam.com.au with SMTP; 7 Oct 2002 06:10:48 -0000 Message-ID: <3DA128C4.D77A7CD0@adam.com.au> Date: Mon, 07 Oct 2002 15:55:08 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> Content-Type: multipart/mixed; boundary="------------F2A44B5CB27819F2BB32557D" X-archive-position: 830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------F2A44B5CB27819F2BB32557D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, > > "Kernel Panic. VFS unable to mount file system 03:02" > > "Invalid Magic SB Number" > > the root device is /hde/hda2 right? > > what does "xfs_check /dev/hda2" print? I don't know at the moment -- it's currently mounted under my working 2.4.18 kernel...I'll have a look very soon :-) DSL -- You'll be lost, so sorry when I'm gone! (Jesus Christ, in Lloyd Webber's Superstar) --------------F2A44B5CB27819F2BB32557D Content-Type: text/x-vcard; charset=us-ascii; name="lloy0076.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Lloyd Content-Disposition: attachment; filename="lloy0076.vcf" begin:vcard n:Lloyd;David tel;cell:+61 4 02 44 09 93 tel;home:+61 8 8165 0305 x-mozilla-html:FALSE url:http://www.rebel.net.au/~lloy0076 adr:;;131 St Bernards Road;Rostrevor;South Australia;5073;Australia version:2.1 email;internet:lloy0076@adam.com.au x-mozilla-cpt:;0 fn:David Lloyd end:vcard --------------F2A44B5CB27819F2BB32557D-- From owner-linux-xfs@oss.sgi.com Sun Oct 6 23:12:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 23:12:50 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g976CmtG007119 for ; Sun, 6 Oct 2002 23:12:48 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 2833AF6B4; Sun, 6 Oct 2002 23:12:48 -0700 (PDT) Date: Sun, 6 Oct 2002 23:12:48 -0700 From: Chris Wedgwood To: David Lloyd Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System Message-ID: <20021007061248.GB22104@tapu.f00f.org> References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA128C4.D77A7CD0@adam.com.au> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Mon, Oct 07, 2002 at 03:55:08PM +0930, David Lloyd wrote: > I don't know at the moment -- it's currently mounted under my > working 2.4.18 kernel...I'll have a look very soon :-) You mean it's mounted now with a different kernel? What does /proc/cmdline say? --cw From owner-linux-xfs@oss.sgi.com Sun Oct 6 23:20:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Oct 2002 23:20:23 -0700 (PDT) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g976KKtG008131 for ; Sun, 6 Oct 2002 23:20:21 -0700 Received: (qmail 62836 invoked from network); 7 Oct 2002 06:20:15 -0000 Received: from 202-6-129-125.ip.adam.com.au (HELO adam.com.au) (202.6.129.125) by eden.adam.com.au with SMTP; 7 Oct 2002 06:20:15 -0000 Message-ID: <3DA12AFB.A680311D@adam.com.au> Date: Mon, 07 Oct 2002 16:04:35 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> Content-Type: multipart/mixed; boundary="------------C4543FEAADB0B08A7F8418F4" X-archive-position: 832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------C4543FEAADB0B08A7F8418F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, > > I don't know at the moment -- it's currently mounted under my > > working 2.4.18 kernel...I'll have a look very soon :-) I am reasonably certain that the 2.4.18 kernel is an RPM from the SGI web-site. It's not a redhat kernel, a standard one. > You mean it's mounted now with a different kernel? What does > /proc/cmdline say? [lloy0076@linux lloy0076]$ cat /proc/cmdline auto BOOT_IMAGE=linux ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.18-SGI_XFS_1.1 ramdisk_size=4096 devfs=nomount ...is what it says :-) DSL -- You'll be lost, so sorry when I'm gone! (Jesus Christ, in Lloyd Webber's Superstar) --------------C4543FEAADB0B08A7F8418F4 Content-Type: text/x-vcard; charset=us-ascii; name="lloy0076.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Lloyd Content-Disposition: attachment; filename="lloy0076.vcf" begin:vcard n:Lloyd;David tel;cell:+61 4 02 44 09 93 tel;home:+61 8 8165 0305 x-mozilla-html:FALSE url:http://www.rebel.net.au/~lloy0076 adr:;;131 St Bernards Road;Rostrevor;South Australia;5073;Australia version:2.1 email;internet:lloy0076@adam.com.au x-mozilla-cpt:;0 fn:David Lloyd end:vcard --------------C4543FEAADB0B08A7F8418F4-- From owner-linux-xfs@oss.sgi.com Mon Oct 7 01:33:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 01:33:47 -0700 (PDT) Received: from chacho.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g978XStG012494 for ; Mon, 7 Oct 2002 01:33:39 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by chacho.sgo.es (8.11.6/8.11.6) id g978Z9B13122 for linux-xfs@oss.sgi.com; Mon, 7 Oct 2002 10:35:09 +0200 Message-Id: <200210070835.g978Z9B13122@chacho.sgo.es> Content-Type: text/plain; charset="iso-8859-15" From: Miguel ANgel To: linux-xfs@oss.sgi.com Subject: can see in linux an IRIX disk or linux disk in IRIX? Date: Mon, 7 Oct 2002 10:34:09 +0200 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mvega@sgo.es Precedence: bulk X-list: linux-xfs Hi! I have tryed to mount a disk in one of these platforms using xfs and see in the otherone, but I had no success. I had make the filesystem in both machines, when I make it in IRIX (with blocksize 4k and default settings) I can see the partitions in linux with fdisk but can't mount anything and when I make in linux, at the IRIX the partitions don't appears. I'm doing something wrong or this is not possible?? thanks and sorry for poor english :P Miguel Angel de Vega Fernandez (spain) From owner-linux-xfs@oss.sgi.com Mon Oct 7 02:16:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 02:16:46 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g979GitG015650 for ; Mon, 7 Oct 2002 02:16:44 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 74F67FD11; Mon, 7 Oct 2002 02:16:44 -0700 (PDT) Date: Mon, 7 Oct 2002 02:16:44 -0700 From: Chris Wedgwood To: Miguel ANgel Cc: linux-xfs@oss.sgi.com Subject: Re: can see in linux an IRIX disk or linux disk in IRIX? Message-ID: <20021007091644.GA23465@tapu.f00f.org> References: <200210070835.g978Z9B13122@chacho.sgo.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210070835.g978Z9B13122@chacho.sgo.es> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Mon, Oct 07, 2002 at 10:34:09AM +0200, Miguel ANgel wrote: > I had make the filesystem in both machines, when I make it in IRIX > (with blocksize 4k and default settings) I can see the partitions in > linux with fdisk but can't mount anything and when I make in linux, > at the IRIX the partitions don't appears. Linux can be made to see SGI disklabels (partitions), I don't beleive IRIX can be makde to see the MS-DOS paritions Linux tools use by default. Under Linux, you *should* be able to mount the IRIX filesystems. What happens when you try? --cw From owner-linux-xfs@oss.sgi.com Mon Oct 7 03:40:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 03:41:02 -0700 (PDT) Received: from mario.gams.at (mario.gams.at [194.42.96.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97AestG017640 for ; Mon, 7 Oct 2002 03:40:55 -0700 Received: from merlin.gams.co.at (IDENT:root@[193.46.232.13]) by mario.gams.at (8.9.3/8.9.3) with ESMTP id MAA23793 for ; Mon, 7 Oct 2002 12:40:23 +0200 Received: from frodo.gams.co.at (IDENT:root@frodo.gams.co.at [193.46.232.160]) by merlin.gams.co.at (8.9.3/8.9.3) with ESMTP id MAA18136 for ; Mon, 7 Oct 2002 12:40:22 +0200 Received: from frodo.gams.co.at (IDENT:bernd@localhost [127.0.0.1]) by frodo.gams.co.at (8.11.6/8.11.6) with ESMTP id g97AeMH09448 for ; Mon, 7 Oct 2002 12:40:22 +0200 Message-Id: <200210071040.g97AeMH09448@frodo.gams.co.at> X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.3 From: Bernd Petrovitsch To: "Linux XFS (SGI)" Subject: Auto-Update (was: Re: RedHat 8.0 and XFS, the sad story continues ...) References: <1033669289.7966.74.camel@locutus.libc.org> In-reply-to: Your message of "03 Oct 2002 12:21:29 MDT." <1033669289.7966.74.camel@locutus.libc.org> X-url: http://www.luga.at/~bernd/ Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 07 Oct 2002 12:40:22 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g97AeutG017641 X-archive-position: 835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bernd@gams.at Precedence: bulk X-list: linux-xfs Bill Anderson wrote: >On Thu, 2002-10-03 at 10:59, Theo Van Dinter wrote: [...] >> up2date would probably work too (update redhat-release, then let it go >> do its thing), although I haven't tried it yet. > >I have. :^) I actually did it (upgraded form 7.2 to 7.3 anyway) with >Ximian as well. Works well enough so far. :) RedHat-6.2 -> RedHat-7.3 with Ximian red-carpet worked without any problems here (well, I'm running the 6.2s original 2.2.14 kernel since the upgrade kernels (2.2.19) and 7.3s kernels (2.4) do not work with the PCMCIA-network card on the Toshiba laptop - and no time up to now to look further into it). Bernd -- Bernd Petrovitsch Email : bernd@gams.at g.a.m.s gmbh Fax : +43 1 205255-900 Prinz-Eugen-Stra遝 8 A-1040 Vienna/Austria/Europe LUGA : http://www.luga.at From owner-linux-xfs@oss.sgi.com Mon Oct 7 05:45:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 05:45:14 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97CjCtG023478 for ; Mon, 7 Oct 2002 05:45:12 -0700 Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17yXFy-0001BS-00 for linux-xfs@oss.sgi.com; Mon, 07 Oct 2002 13:45:06 +0100 Message-ID: <3DA181D2.B78A9C41@moving-picture.com> Date: Mon, 07 Oct 2002 13:45:06 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Log corruption? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS 1.1 kernel - every now and then a (different) machine will crash/hang and fail to boot with a kernel oops and/or with XFS errors when it tries to mount the root file system. The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' on the root partition. The root file system is them mountable and the machine reboots OK. I don't have exact error messages (don't have time to write down the exact errors, as the priority is to get the machine up and running ...) Is this a known problem? If it isn't, I'll attempt to get more information when it happens again. James Pearson From owner-linux-xfs@oss.sgi.com Mon Oct 7 05:58:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 05:58:37 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97CwYtG032229 for ; Mon, 7 Oct 2002 05:58:34 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA68335; Mon, 7 Oct 2002 07:58:28 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-22.corp.sgi.com [134.15.64.22]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA73406; Mon, 7 Oct 2002 07:58:26 -0500 (CDT) Subject: Re: can see in linux an IRIX disk or linux disk in IRIX? From: Stephen Lord To: Miguel ANgel Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210070835.g978Z9B13122@chacho.sgo.es> References: <200210070835.g978Z9B13122@chacho.sgo.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Oct 2002 07:55:02 -0500 Message-Id: <1033995306.1054.18.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-10-07 at 03:34, Miguel ANgel wrote: > Hi! > > I have tryed to mount a disk in one of these platforms using xfs and see in > the otherone, but I had no success. > I had make the filesystem in both machines, when I make it in IRIX (with > blocksize 4k and default settings) I can see the partitions in linux with > fdisk but can't mount anything and when I make in linux, at the IRIX the > partitions don't appears. > > I'm doing something wrong or this is not possible?? > > thanks and sorry for poor english :P > > Miguel Angel de Vega Fernandez (spain) > Log formats are incompatible between Irix and Linux, an Irix filesystem must be cleanly unmounted first, or run xfs_repair -L on it to zero the log - in fact you may have to do this. I did just mount an Irix filesystem (made in a file not on a partition) on linux without problem this morning. Steve From owner-linux-xfs@oss.sgi.com Mon Oct 7 06:04:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 06:04:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97D4PtG000444 for ; Mon, 7 Oct 2002 06:04:25 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA73843; Mon, 7 Oct 2002 08:04:19 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-22.corp.sgi.com [134.15.64.22]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA67885; Mon, 7 Oct 2002 08:04:12 -0500 (CDT) Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System From: Stephen Lord To: David Lloyd Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <3DA12AFB.A680311D@adam.com.au> References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Oct 2002 08:00:49 -0500 Message-Id: <1033995657.1054.25.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-10-07 at 01:34, David Lloyd wrote: > > Chris, > > > > I don't know at the moment -- it's currently mounted under my > > > working 2.4.18 kernel...I'll have a look very soon :-) > > I am reasonably certain that the 2.4.18 kernel is an RPM from the SGI > web-site. It's not a redhat kernel, a standard one. > > > You mean it's mounted now with a different kernel? What does > > /proc/cmdline say? > > [lloy0076@linux lloy0076]$ cat /proc/cmdline > auto BOOT_IMAGE=linux ro root=302 > BOOT_FILE=/boot/vmlinuz-2.4.18-SGI_XFS_1.1 ramdisk_size=4096 > devfs=nomount > > ...is what it says :-) > I definitely have old filesystems which mount without issues. I suspect you have a kernel configuration issue and the message you are getting is not from XFS. If XFS fails to recognize the super block it prints this: XFS: bad magic number XFS: SB validate failed Do you actually have xfs built into the new kernel? Steve From owner-linux-xfs@oss.sgi.com Mon Oct 7 06:15:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 06:15:05 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97DF0tG001251 for ; Mon, 7 Oct 2002 06:15:00 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA96828; Mon, 7 Oct 2002 08:14:55 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-22.corp.sgi.com [134.15.64.22]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA72758; Mon, 7 Oct 2002 08:14:55 -0500 (CDT) Subject: Re: Log corruption? From: Stephen Lord To: James Pearson Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DA181D2.B78A9C41@moving-picture.com> References: <3DA181D2.B78A9C41@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Oct 2002 08:11:31 -0500 Message-Id: <1033996292.1053.32.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-10-07 at 07:45, James Pearson wrote: > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > 1.1 kernel - every now and then a (different) machine will crash/hang > and fail to boot with a kernel oops and/or with XFS errors when it tries > to mount the root file system. > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > on the root partition. The root file system is them mountable and the > machine reboots OK. > > I don't have exact error messages (don't have time to write down the > exact errors, as the priority is to get the machine up and running ...) > > Is this a known problem? If it isn't, I'll attempt to get more > information when it happens again. > > James Pearson > Actually, a change just went into the cvs tree this weekend which might be related to this, there is some zeroing of part of the log which is always supposed to happen during mount. For a readonly mount this was not happening - and the root is mounted this way. Should the machine be shutdown and rebooted very shortly after this there is a possibility of the second mount getting confused by the log contents. Is there any way this could be what is happening? Is this happening on the second of two boots which are close together? Currently there is no way to get this code except from a cvs kernel, we just put out some images of the first alpha of xfs 1.2, the next spin of these should include this fix (hint hint Eric). Steve From owner-linux-xfs@oss.sgi.com Mon Oct 7 06:44:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 06:44:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97DintG001864 for ; Mon, 7 Oct 2002 06:44:49 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA81613; Mon, 7 Oct 2002 08:44:44 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA19219; Mon, 7 Oct 2002 08:44:43 -0500 (CDT) Subject: Re: Log corruption? From: Eric Sandeen To: Stephen Lord Cc: James Pearson , linux-xfs@oss.sgi.com In-Reply-To: <1033996292.1053.32.camel@laptop.americas.sgi.com> References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Oct 2002 08:42:43 -0500 Message-Id: <1033998164.1700.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I'll merge the code to the 1.2 tree, so it's available in the next test release (hint hint Russell). -Eric On Mon, 2002-10-07 at 08:11, Stephen Lord wrote: > Currently there is no way to get this code except from a cvs kernel, > we just put out some images of the first alpha of xfs 1.2, the next > spin of these should include this fix (hint hint Eric). > > Steve > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Oct 7 07:03:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 07:03:06 -0700 (PDT) Received: from netm1.net-m.de (ad96e0a04.dsl.de.colt.net [217.110.10.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97E2wtG003049 for ; Mon, 7 Oct 2002 07:03:02 -0700 Received: from wwodecki.net-m.de ([192.168.154.150]) by netm1.net-m.de with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Oct 2002 16:02:53 +0200 Received: (from wwodecki@localhost) by wwodecki.net-m.de (8.11.6/8.11.6) id g97E2rP11764 for linux-xfs@oss.sgi.com; Mon, 7 Oct 2002 16:02:53 +0200 Date: Mon, 7 Oct 2002 16:02:52 +0200 From: Wiktor Wodecki To: linux-xfs@oss.sgi.com Subject: getfacl misleading Message-ID: <20021007160252.C10873@wwodecki.net-m.de> Reply-To: wiktor.wodecki@net-m.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-message-flag: Linux - choice of the GNU generation X-Operating-System: Linux 2.4.19-ck7 i686 X-OriginalArrivalTime: 07 Oct 2002 14:02:53.0032 (UTC) FILETIME=[3A850680:01C26E0A] X-archive-position: 841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wiktor.wodecki@net-m.de Precedence: bulk X-list: linux-xfs Hello, it seems that getfacl is missing default access *sometimes*. What I did: [root@file1 Controlling]# getfacl _netm/ # file: _netm # owner: root # group: root user::rwx group::r-x other::--- [root@file1 Controlling]# setfacl -d -m g:group2:rwx _netm/ [root@file1 Controlling]# getfacl _netm/ # file: _netm # owner: root # group: root user::rwx group::r-x other::--- default:user::rwx default:group::r-x default:group:group2:rwx default:mask::rwx default:other::--- [root@file1 Controlling]# setfacl -d -m g:group1:rx _netm/ [root@file1 Controlling]# getfacl _netm/ # file: _netm # owner: root # group: root user::rwx group::r-x other::--- default:user::rwx default:group::r-x default:group:group1:r-x default:mask::rwx default:other::--- [root@file1 Controlling]# chacl -l _netm/ _netm/ [u::rwx,g::r-x,o::---/u::rwx,g::r-x,g:group1:r-x,g:group2:rwx,m::rwx,o::---] [root@file1 Controlling]# As you can see with chacl the default for the group group2 is there, however not beeing displayed by getfacl. The curious thing is, that when I add another group to the default list it get's displayed properly: [root@file1 Controlling]# setfacl -d -m g:group3:rwx _netm/ [root@file1 Controlling]# getfacl _netm/ # file: _netm # owner: root # group: root user::rwx group::r-x other::--- default:user::rwx default:group::r-x default:group:group1:r-x default:group:group2:rwx default:group:group3:rwx default:mask::rwx default:other::--- I understand that the effective rights aren't being displayed, however you might consider changing this behaviour, since it's pretty confusing. One has to use --all-effective to display full rights. Please keep me in CC since I'm not subscribed to this list. -- Regards, Wiktor Wodecki From owner-linux-xfs@oss.sgi.com Mon Oct 7 07:07:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 07:07:13 -0700 (PDT) Received: from netm1.net-m.de (ad96e0a04.dsl.de.colt.net [217.110.10.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97E7AtG003368 for ; Mon, 7 Oct 2002 07:07:11 -0700 Received: from wwodecki.net-m.de ([192.168.154.150]) by netm1.net-m.de with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Oct 2002 16:07:04 +0200 Received: (from wwodecki@localhost) by wwodecki.net-m.de (8.11.6/8.11.6) id g97E74L11917 for linux-xfs@oss.sgi.com; Mon, 7 Oct 2002 16:07:04 +0200 Date: Mon, 7 Oct 2002 16:07:04 +0200 From: Wiktor Wodecki To: linux-xfs@oss.sgi.com Subject: Re: getfacl misleading Message-ID: <20021007160704.D10873@wwodecki.net-m.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-message-flag: Linux - choice of the GNU generation X-Operating-System: Linux 2.4.19-ck7 i686 X-OriginalArrivalTime: 07 Oct 2002 14:07:04.0990 (UTC) FILETIME=[D0B2C3E0:01C26E0A] X-archive-position: 842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wiktor.wodecki@net-m.de Precedence: bulk X-list: linux-xfs oh please ignore my previous post, my acl utils were really old, I upgraded them to 2.0.18 and now it's working as expected :-) -- Regards, Wiktor Wodecki From owner-linux-xfs@oss.sgi.com Mon Oct 7 07:21:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 07:21:22 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97ELJtG004094 for ; Mon, 7 Oct 2002 07:21:20 -0700 Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 17yYky-0003Mi-00; Mon, 07 Oct 2002 15:21:12 +0100 Message-ID: <3DA19858.75C9E674@moving-picture.com> Date: Mon, 07 Oct 2002 15:21:12 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: linux-xfs@oss.sgi.com Subject: Re: Log corruption? References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs The sequence of events is: Machine locks up - probably related to some Xwindows/application problem (we use the Nvidia drivers) Machine is reset Kernel boots Fails to mount the root (XFS) file system - either with an oops of some error telling us the file system is corrupt etc. Attempts to reset again produce same results above. Booting in rescue mode, running 'xfs_repair -L' and rebooting "fixes" the problem. xfs_repair finds some lost file and puts them in lost+found - these are usually files from /tmp or /var/tmp. This doesn't happen every time a machine locks up, but it occurs may be once a week or so on one or another of our 60 or so workstations. James Pearson Stephen Lord wrote: > > On Mon, 2002-10-07 at 07:45, James Pearson wrote: > > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > > 1.1 kernel - every now and then a (different) machine will crash/hang > > and fail to boot with a kernel oops and/or with XFS errors when it tries > > to mount the root file system. > > > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > > on the root partition. The root file system is them mountable and the > > machine reboots OK. > > > > I don't have exact error messages (don't have time to write down the > > exact errors, as the priority is to get the machine up and running ...) > > > > Is this a known problem? If it isn't, I'll attempt to get more > > information when it happens again. > > > > James Pearson > > > > Actually, a change just went into the cvs tree this weekend which might > be related to this, there is some zeroing of part of the log which is > always supposed to happen during mount. For a readonly mount this was > not happening - and the root is mounted this way. Should the machine > be shutdown and rebooted very shortly after this there is a possibility > of the second mount getting confused by the log contents. > > Is there any way this could be what is happening? Is this happening > on the second of two boots which are close together? > > Currently there is no way to get this code except from a cvs kernel, > we just put out some images of the first alpha of xfs 1.2, the next > spin of these should include this fix (hint hint Eric). > > Steve From owner-linux-xfs@oss.sgi.com Mon Oct 7 07:22:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 07:22:44 -0700 (PDT) Received: from mailhub-1.iastate.edu (mailhub-1.iastate.edu [129.186.140.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97EMetG004233 for ; Mon, 7 Oct 2002 07:22:41 -0700 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-1.iastate.edu (8.9.3/8.9.3) with SMTP id JAA32733 for ; Mon, 7 Oct 2002 09:22:40 -0500 Received: from pircsds0.agron.iastate.edu(129.186.26.63) by mailout-1.iastate.edu via csmap id 2052; Mon, 07 Oct 2002 09:33:28 -0500 (CDT) Date: Mon, 7 Oct 2002 09:22:39 -0500 (CDT) From: Daryl Herzmann X-X-Sender: akrherz@pircsds0.agron.iastate.edu To: linux-xfs@oss.sgi.com Subject: 2.4.18-14SGI_XFS_1.2a1 oops && raid5 troubles Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1165934822-433558079-1034000559=:4175" X-archive-position: 844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akrherz@iastate.edu Precedence: bulk X-list: linux-xfs This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1165934822-433558079-1034000559=:4175 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! You all have been great help in the past. Hopefully you can help me save my 800+ GB data partition! It all started after a sucessful upgrade to RH 8.0 . I swapped video cards to play with a Matrox G450 and everything locked hard after starting X once, screen went dark, no ethernet response. So I hard reset So once the machine rebooted, my raid5 array (8x120, no spares) started a reconstruction. After about 20 minutes, I got this error Oct 4 21:05:28 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComplete Error } Oct 4 21:05:28 pircsds0 kernel: hdf: dma_intr: error=0x01 { AddrMarkNotFound }, LBAsect=43686424, high=2, low=10131992, sector=43686315 Oct 4 21:05:30 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComplete Error } Oct 4 21:05:30 pircsds0 kernel: hdf: dma_intr: error=0x01 { AddrMarkNotFound }, LBAsect=43686424, high=2, low=10131992, sector=43686315 Oct 4 21:05:31 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComplete Error } Oct 4 21:05:31 pircsds0 kernel: hdf: dma_intr: error=0x40 { UncorrectableError }, LBAsect=43686424, high=2, low=10131992, sector=43686315 Oct 4 21:05:31 pircsds0 kernel: end_request: I/O error, dev 21:41 (hdf), sector 43686315 From the syslogs, the raid array went into degradded and then the machine locked up. Again no eth0 or video. So I hard reset again Seeing those DMA errors, I decided to disable DMA for the drives and then let it reconstruct that way. Well, the estimations were about 15 days for raid reconstruction, so I just disabled DMA for hdf. After about 90 minutes, hdl produced the same DMA errors. Sooo, I stopped everything, marked hdf1 as being a failed disk and started raid5 in degradded mode. At this point, I am getting desperate :) So I ran xfs_repair on /dev/md0 and did not get any errors, so I mounted the device, again no errors. I then tried doing a simple 'ls -l' in the top level directory and immediately got this (Attached as error.txt) So I ran ksymoops on it and that is attached as well (ksymoops.txt) Does anybody have any ideas about how to proceed? Some other bits of information are 1. I am using 36 inch 80 pin cables 2. The eight drives are on two Promise PDC20269 TX2 Ultra-133 controllers 3. This array has been functional for over 10 months, but it has never experienced a crash/hard reset. 4. This is not the same system that I have reported raid5/XFS troubles before. Thanks, Daryl -- /** * Daryl Herzmann (akrherz@iastate.edu) * Program Assistant -- Iowa Environmental Mesonet * http://mesonet.agron.iastate.edu */ ---1165934822-433558079-1034000559=:4175 Content-Type: TEXT/plain; name="error.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="error.txt" T2N0ICA3IDA2OjU3OjQ4IHBpcmNzZHMwIGtlcm5lbDogVW5hYmxlIHRvIGhh bmRsZSBrZXJuZWwgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGF0IHZpcnR1 YWwgYWRkcmVzcyAwMDAwMDAwMCANCk9jdCAgNyAwNjo1Nzo0OCBwaXJjc2Rz MCBrZXJuZWw6ICBwcmludGluZyBlaXA6IA0KT2N0ICA3IDA2OjU3OjQ4IHBp cmNzZHMwIGtlcm5lbDogYzAxMzU3ZGUgDQpPY3QgIDcgMDY6NTc6NDggcGly Y3NkczAga2VybmVsOiAqcGRlID0gMDAwMDAwMDAgDQpPY3QgIDcgMDY6NTc6 NDggcGlyY3NkczAga2VybmVsOiBPb3BzOiAwMDAyIA0KT2N0ICA3IDA2OjU3 OjQ4IHBpcmNzZHMwIGtlcm5lbDogYmluZm10X21pc2MgbmZzZCBwYXJwb3J0 X3BjIGxwIHBhcnBvcnQgYXV0b2ZzIG5mcyBsb2NrZCBzdW5ycGMgZWVwcm8x MDAgaXB0YWJsIA0KT2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDog Q1BVOiAgICAwIA0KT2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDog RUlQOiAgICAwMDEwOltdICAgIE5vdCB0YWludGVkIA0KT2N0ICA3IDA2OjU3 OjQ5IHBpcmNzZHMwIGtlcm5lbDogRUZMQUdTOiAwMDAxMDAxMiANCk9jdCAg NyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6ICANCk9jdCAgNyAwNjo1Nzo0 OSBwaXJjc2RzMCBrZXJuZWw6IEVJUCBpcyBhdCBrbWVtX2ZpbmRfZ2VuZXJh bF9jYWNoZXBfUjUyYmI2ODkxIFtdIDB4NWJlICgyLjQuMTgtMTRTR0lfWEZT XzEuMmExKSANCk9jdCAgNyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6IGVh eDogMDAwMDAwMDAgICBlYng6IGMzNmIzODYwICAgZWN4OiBmNTg4MGNhMCAg IGVkeDogZjU3ZTQzYTAgDQpPY3QgIDcgMDY6NTc6NDkgcGlyY3NkczAga2Vy bmVsOiBlc2k6IGMzNmIzODU4ICAgZWRpOiAwMDAwMDI0NiAgIGVicDogMDAw MDAxZjAgICBlc3A6IGY1NmY1ZWNjIA0KT2N0ICA3IDA2OjU3OjQ5IHBpcmNz ZHMwIGtlcm5lbDogZHM6IDAwMTggICBlczogMDAxOCAgIHNzOiAwMDE4IA0K T2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDogUHJvY2VzcyBscyAo cGlkOiA5MjAsIHN0YWNrcGFnZT1mNTZmNTAwMCkgDQpPY3QgIDcgMDY6NTc6 NDkgcGlyY3NkczAga2VybmVsOiBTdGFjazogMDAwMDEwMDAgZjdiODJlYTAg ZjY0NjkzZGMgMDAwMDAwMDAgZjY0Njk0NDggMDAwMDQwMDAgYzAxZTFkNzAg YzM2YjM4NTggIA0KT2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDog ICAgICAgIDAwMDAwMWYwIDAwMDAwMDAxIDA4MDVmZjNjIDAwMDAzYTg5IGY3 YjgyZWEwIGY3YjgyZWJjIDA4MDVmZjNjIDAwMDAwMDAwICANCk9jdCAgNyAw Njo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6ICAgICAgICBjMDExNjlmOCBmNjQ2 OTNjMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMSBmNTZmNDAwMCAwMDAw MDAwMSAwMDAwMDAwMCAgDQpPY3QgIDcgMDY6NTc6NDkgcGlyY3NkczAga2Vy bmVsOiBDYWxsIFRyYWNlOiBbXSBwYWdlYnVmX29mZnNldF9SOTA2YTViMGMg W10gMHgyZGEwICgweGY1NmY1ZWU0KSkgDQpPY3QgIDcgMDY6NTc6NDkgcGly Y3NkczAga2VybmVsOiBbXSBfX3ZlcmlmeV93cml0ZV9SMjAzYWZiZWIgW10g MHgyYTggKDB4ZjU2ZjVmMGMpKSANCk9jdCAgNyAwNjo1Nzo0OSBwaXJjc2Rz MCBrZXJuZWw6IFtdIHZmc19yZWFkZGlyX1I4NzhmYTgwMyBbXSAweDlkICgw eGY1NmY1ZjU0KSkgDQpPY3QgIDcgMDY6NTc6NDkgcGlyY3NkczAga2VybmVs OiBbXSBvbGRfcmVhZGRpcl9SYzZiYmQ0YzQgW10gMHgyMTAgKDB4ZjU2ZjVm NjApKSANCk9jdCAgNyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6IFtdIG9s ZF9yZWFkZGlyX1JjNmJiZDRjNCBbXSAweDM3YiAoMHhmNTZmNWY3NCkpIA0K T2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDogW10gb2xkX3JlYWRk aXJfUmM2YmJkNGM0IFtdIDB4MjEwICgweGY1NmY1ZjdjKSkgDQpPY3QgIDcg MDY6NTc6NDkgcGlyY3NkczAga2VybmVsOiBbXSBzeXNfYnJrX1JlMGIyMzM0 ZiBbXSAweGY3ICgweGY1NmY1Zjk0KSkgDQpPY3QgIDcgMDY6NTc6NDkgcGly Y3NkczAga2VybmVsOiBbXSBzeXNfc2lnYWx0c3RhY2tfUmFiNjU1MzZiIFtd IDB4ZjdmICgweGY1NmY1ZmMwKSkgDQpPY3QgIDcgMDY6NTc6NTAgcGlyY3Nk czAga2VybmVsOiAgDQpPY3QgIDcgMDY6NTc6NTAgcGlyY3NkczAga2VybmVs OiAgDQpPY3QgIDcgMDY6NTc6NTAgcGlyY3NkczAga2VybmVsOiBDb2RlOiA4 OSAxMCA4OSA0MiAwNCA4YiA0NiAwOCA4OSA0OCAwNCA4OSAwMSA4OSA1OSAw NCA4OSA0ZSAwOCBlYg0K ---1165934822-433558079-1034000559=:4175 Content-Type: TEXT/plain; name="ksymoops.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ksymoops.txt" a3N5bW9vcHMgMi40LjUgb24gaTY4NiAyLjQuMTgtMTRTR0lfWEZTXzEuMmEx LiAgT3B0aW9ucyB1c2VkDQogICAgIC1WIChkZWZhdWx0KQ0KICAgICAtayAv cHJvYy9rc3ltcyAoZGVmYXVsdCkNCiAgICAgLWwgL3Byb2MvbW9kdWxlcyAo ZGVmYXVsdCkNCiAgICAgLW8gL2xpYi9tb2R1bGVzLzIuNC4xOC0xNFNHSV9Y RlNfMS4yYTEvIChkZWZhdWx0KQ0KICAgICAtbSAvYm9vdC9TeXN0ZW0ubWFw LTIuNC4xOC0xNFNHSV9YRlNfMS4yYTEgKGRlZmF1bHQpDQoNCldhcm5pbmc6 IFlvdSBkaWQgbm90IHRlbGwgbWUgd2hlcmUgdG8gZmluZCBzeW1ib2wgaW5m b3JtYXRpb24uICBJIHdpbGwNCmFzc3VtZSB0aGF0IHRoZSBsb2cgbWF0Y2hl cyB0aGUga2VybmVsIGFuZCBtb2R1bGVzIHRoYXQgYXJlIHJ1bm5pbmcNCnJp Z2h0IG5vdyBhbmQgSSdsbCB1c2UgdGhlIGRlZmF1bHQgb3B0aW9ucyBhYm92 ZSBmb3Igc3ltYm9sIHJlc29sdXRpb24uDQpJZiB0aGUgY3VycmVudCBrZXJu ZWwgYW5kL29yIG1vZHVsZXMgZG8gbm90IG1hdGNoIHRoZSBsb2csIHlvdSBj YW4gZ2V0DQptb3JlIGFjY3VyYXRlIG91dHB1dCBieSB0ZWxsaW5nIG1lIHRo ZSBrZXJuZWwgdmVyc2lvbiBhbmQgd2hlcmUgdG8gZmluZA0KbWFwLCBtb2R1 bGVzLCBrc3ltcyBldGMuICBrc3ltb29wcyAtaCBleHBsYWlucyB0aGUgb3B0 aW9ucy4NCg0KRXJyb3IgKGV4cGFuZF9vYmplY3RzKTogY2Fubm90IHN0YXQo L2xpYi9leHQzLm8pIGZvciBleHQzDQpFcnJvciAoZXhwYW5kX29iamVjdHMp OiBjYW5ub3Qgc3RhdCgvbGliL2piZC5vKSBmb3IgamJkDQpFcnJvciAoZXhw YW5kX29iamVjdHMpOiBjYW5ub3Qgc3RhdCgvbGliL3JhaWQ1Lm8pIGZvciBy YWlkNQ0KRXJyb3IgKGV4cGFuZF9vYmplY3RzKTogY2Fubm90IHN0YXQoL2xp Yi94b3IubykgZm9yIHhvcg0KRXJyb3IgKHBjbG9zZV9sb2NhbCk6IGZpbmRf b2JqZWN0cyBwY2xvc2UgZmFpbGVkIDB4MTAwDQpXYXJuaW5nIChtYXBfa3N5 bV90b19tb2R1bGUpOiBjYW5ub3QgbWF0Y2ggbG9hZGVkIG1vZHVsZSBleHQz IHRvIGEgdW5pcXVlIG1vZHVsZSBvYmplY3QuICBUcmFjZSBtYXkgbm90IGJl IHJlbGlhYmxlLg0KT2N0ICA3IDA2OjU3OjQ4IHBpcmNzZHMwIGtlcm5lbDog VW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgTlVMTCBwb2ludGVyIGRlcmVmZXJl bmNlIGF0IHZpcnR1YWwgYWRkcmVzcyAwMDAwMDAwMCANCk9jdCAgNyAwNjo1 Nzo0OCBwaXJjc2RzMCBrZXJuZWw6IGMwMTM1N2RlIA0KT2N0ICA3IDA2OjU3 OjQ4IHBpcmNzZHMwIGtlcm5lbDogKnBkZSA9IDAwMDAwMDAwIA0KT2N0ICA3 IDA2OjU3OjQ4IHBpcmNzZHMwIGtlcm5lbDogT29wczogMDAwMiANCk9jdCAg NyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6IENQVTogICAgMCANCk9jdCAg NyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6IEVJUDogICAgMDAxMDpbXSAg ICBOb3QgdGFpbnRlZCANCk9jdCAgNyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJu ZWw6IEVGTEFHUzogMDAwMTAwMTIgDQpPY3QgIDcgMDY6NTc6NDkgcGlyY3Nk czAga2VybmVsOiBlYXg6IDAwMDAwMDAwICAgZWJ4OiBjMzZiMzg2MCAgIGVj eDogZjU4ODBjYTAgICBlZHg6IGY1N2U0M2EwIA0KT2N0ICA3IDA2OjU3OjQ5 IHBpcmNzZHMwIGtlcm5lbDogZXNpOiBjMzZiMzg1OCAgIGVkaTogMDAwMDAy NDYgICBlYnA6IDAwMDAwMWYwICAgZXNwOiBmNTZmNWVjYyANCk9jdCAgNyAw Njo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6IGRzOiAwMDE4ICAgZXM6IDAwMTgg ICBzczogMDAxOCANCk9jdCAgNyAwNjo1Nzo0OSBwaXJjc2RzMCBrZXJuZWw6 IFByb2Nlc3MgbHMgKHBpZDogOTIwLCBzdGFja3BhZ2U9ZjU2ZjUwMDApIA0K T2N0ICA3IDA2OjU3OjQ5IHBpcmNzZHMwIGtlcm5lbDogU3RhY2s6IDAwMDAx MDAwIGY3YjgyZWEwIGY2NDY5M2RjIDAwMDAwMDAwIGY2NDY5NDQ4IDAwMDA0 MDAwIGMwMWUxZDcwIGMzNmIzODU4ICANCk9jdCAgNyAwNjo1Nzo0OSBwaXJj c2RzMCBrZXJuZWw6ICAgICAgICAwMDAwMDFmMCAwMDAwMDAwMSAwODA1ZmYz YyAwMDAwM2E4OSBmN2I4MmVhMCBmN2I4MmViYyAwODA1ZmYzYyAwMDAwMDAw MCAgDQpPY3QgIDcgMDY6NTc6NDkgcGlyY3NkczAga2VybmVsOiAgICAgICAg YzAxMTY5ZjggZjY0NjkzYzAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDEg ZjU2ZjQwMDAgMDAwMDAwMDEgMDAwMDAwMDAgIA0KT2N0ICA3IDA2OjU3OjQ5 IHBpcmNzZHMwIGtlcm5lbDogQ2FsbCBUcmFjZTogW10gcGFnZWJ1Zl9vZmZz ZXRfUjkwNmE1YjBjIFtdIDB4MmRhMCAoMHhmNTZmNWVlNCkpIA0KV2Fybmlu ZyAoT29wc19yZWFkKTogQ29kZSBsaW5lIG5vdCBzZWVuLCBkdW1waW5nIHdo YXQgZGF0YSBpcyBhdmFpbGFibGUNCg0KDQo+PmVieDsgYzM2YjM4NjAgPF9l bmQrMzI1ODYyMC8zODNjY2UyMD4NCj4+ZWN4OyBmNTg4MGNhMCA8X2VuZCsz NTQyNWE2MC8zODNjY2UyMD4NCj4+ZWR4OyBmNTdlNDNhMCA8X2VuZCszNTM4 OTE2MC8zODNjY2UyMD4NCj4+ZXNpOyBjMzZiMzg1OCA8X2VuZCszMjU4NjE4 LzM4M2NjZTIwPg0KPj5lc3A7IGY1NmY1ZWNjIDxfZW5kKzM1MjlhYzhjLzM4 M2NjZTIwPg0KDQpPY3QgIDcgMDY6NTc6NTAgcGlyY3NkczAga2VybmVsOiBD b2RlOiA4OSAxMCA4OSA0MiAwNCA4YiA0NiAwOCA4OSA0OCAwNCA4OSAwMSA4 OSA1OSAwNCA4OSA0ZSAwOCBlYg0KVXNpbmcgZGVmYXVsdHMgZnJvbSBrc3lt b29wcyAtdCBlbGYzMi1pMzg2IC1hIGkzODYNCg0KDQpDb2RlOyAgMDAwMDAw MDAgQmVmb3JlIGZpcnN0IHN5bWJvbA0KMDAwMDAwMDAgPF9FSVA+Og0KQ29k ZTsgIDAwMDAwMDAwIEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAgIDA6ICAgODkg MTAgICAgICAgICAgICAgICAgICAgICBtb3YgICAgJWVkeCwoJWVheCkNCkNv ZGU7ICAwMDAwMDAwMiBCZWZvcmUgZmlyc3Qgc3ltYm9sDQogICAyOiAgIDg5 IDQyIDA0ICAgICAgICAgICAgICAgICAgbW92ICAgICVlYXgsMHg0KCVlZHgp DQpDb2RlOyAgMDAwMDAwMDUgQmVmb3JlIGZpcnN0IHN5bWJvbA0KICAgNTog ICA4YiA0NiAwOCAgICAgICAgICAgICAgICAgIG1vdiAgICAweDgoJWVzaSks JWVheA0KQ29kZTsgIDAwMDAwMDA4IEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAg IDg6ICAgODkgNDggMDQgICAgICAgICAgICAgICAgICBtb3YgICAgJWVjeCww eDQoJWVheCkNCkNvZGU7ICAwMDAwMDAwYiBCZWZvcmUgZmlyc3Qgc3ltYm9s DQogICBiOiAgIDg5IDAxICAgICAgICAgICAgICAgICAgICAgbW92ICAgICVl YXgsKCVlY3gpDQpDb2RlOyAgMDAwMDAwMGQgQmVmb3JlIGZpcnN0IHN5bWJv bA0KICAgZDogICA4OSA1OSAwNCAgICAgICAgICAgICAgICAgIG1vdiAgICAl ZWJ4LDB4NCglZWN4KQ0KQ29kZTsgIDAwMDAwMDEwIEJlZm9yZSBmaXJzdCBz eW1ib2wNCiAgMTA6ICAgODkgNGUgMDggICAgICAgICAgICAgICAgICBtb3Yg ICAgJWVjeCwweDgoJWVzaSkNCkNvZGU7ICAwMDAwMDAxMyBCZWZvcmUgZmly c3Qgc3ltYm9sDQogIDEzOiAgIGViIDAwICAgICAgICAgICAgICAgICAgICAg am1wICAgIDE1IDxfRUlQKzB4MTU+DQoNCg0KMyB3YXJuaW5ncyBhbmQgNSBl cnJvcnMgaXNzdWVkLiAgUmVzdWx0cyBtYXkgbm90IGJlIHJlbGlhYmxlLg0K ---1165934822-433558079-1034000559=:4175-- From owner-linux-xfs@oss.sgi.com Mon Oct 7 08:13:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 08:13:12 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97FD9tG006413 for ; Mon, 7 Oct 2002 08:13:09 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 8E2BEAC2D; Mon, 7 Oct 2002 17:09:18 +0200 (CEST) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 926CE190CB; Mon, 7 Oct 2002 17:09:17 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 5FABE30881D; Mon, 7 Oct 2002 17:13:06 +0200 (CEST) Message-ID: <3DA1A482.2C3AA6CF@ch.sauter-bc.com> Date: Mon, 07 Oct 2002 17:13:06 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Daryl Herzmann Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18-14SGI_XFS_1.2a1 oops && raid5 troubles References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Daryl Herzmann schrieb: > > Hi! > You all have been great help in the past. Hopefully you can help me > save my 800+ GB data partition! > > It all started after a sucessful upgrade to RH 8.0 . I swapped video > cards to play with a Matrox G450 and everything locked hard after starting > X once, screen went dark, no ethernet response. So I hard reset > > So once the machine rebooted, my raid5 array (8x120, no spares) started a > reconstruction. After about 20 minutes, I got this error > > Oct 4 21:05:28 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Oct 4 21:05:28 pircsds0 kernel: hdf: dma_intr: error=0x01 { > AddrMarkNotFound }, LBAsect=43686424, high=2, low=10131992, > sector=43686315 > Oct 4 21:05:30 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Oct 4 21:05:30 pircsds0 kernel: hdf: dma_intr: error=0x01 { > AddrMarkNotFound }, LBAsect=43686424, high=2, low=10131992, > sector=43686315 > Oct 4 21:05:31 pircsds0 kernel: hdf: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Oct 4 21:05:31 pircsds0 kernel: hdf: dma_intr: error=0x40 { > UncorrectableError }, LBAsect=43686424, high=2, low=10131992, > sector=43686315 > Oct 4 21:05:31 pircsds0 kernel: end_request: I/O error, dev 21:41 (hdf), > sector 43686315 > > >From the syslogs, the raid array went into degradded and then the machine > locked up. Again no eth0 or video. So I hard reset again > > Seeing those DMA errors, I decided to disable DMA for the drives and then > let it reconstruct that way. Well, the estimations were about 15 days > for raid reconstruction, so I just disabled DMA for hdf. After about 90 > minutes, hdl produced the same DMA errors. Sooo, I stopped everything, > marked hdf1 as being a failed disk and started raid5 in degradded mode. I don't think what you see are DMA related problems but just bad sectors on the disks (just my own experience with IBM deathstar disks). The problem is that after a crash the RAID resync detects all those error on the disk which you don't find otherwise because there is no access the the exact location where the disk failed. That's why hardware RAID controllers like 3ware can do background surface check (or how they call it, I don't have 3ware hardware). I'm using 4 disks on a Promise PDC20268 TX2 Ultra-100 controller and had a problem recently. The problem was that I have put two disks per channel and when one disk had a problem, it would block I/O on the channel so the other disks was blocked too and I had a corrupt RAID5. I rebooted, mounted, and it crashed again. I have then physically removed the bad drive and marked it as failed disk in /etc/raidtab. Then I recreated the RAID5 volume with mkraid -f /dev/mdx, which in fact brought the RAID5 back and I was able to mount the XFS volume and it was all fine. HTH Simon > > At this point, I am getting desperate :) So I ran xfs_repair on /dev/md0 > and did not get any errors, so I mounted the device, again no errors. I > then tried doing a simple 'ls -l' in the top level directory and > immediately got this (Attached as error.txt) So I ran ksymoops on it and > that is attached as well (ksymoops.txt) > > Does anybody have any ideas about how to proceed? Some other bits of > information are > > 1. I am using 36 inch 80 pin cables > 2. The eight drives are on two Promise PDC20269 TX2 Ultra-133 > controllers > 3. This array has been functional for over 10 months, but it has never > experienced a crash/hard reset. > 4. This is not the same system that I have reported raid5/XFS troubles > before. > > Thanks, > Daryl > > -- > /** > * Daryl Herzmann (akrherz@iastate.edu) > * Program Assistant -- Iowa Environmental Mesonet > * http://mesonet.agron.iastate.edu > */ > > ------------------------------------------------------------------------ > Name: error.txt > error.txt Type: Plain Text (TEXT/plain) > Encoding: BASE64 > > Name: ksymoops.txt > ksymoops.txt Type: Plain Text (TEXT/plain) > Encoding: BASE64 From owner-linux-xfs@oss.sgi.com Mon Oct 7 12:10:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 12:10:56 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97JAqtG015008 for ; Mon, 7 Oct 2002 12:10:52 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 MAA07054 for ; Mon, 7 Oct 2002 12:10:51 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g97JA1Ix002410 for ; Mon, 7 Oct 2002 21:10:01 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g97JA1Lx002409 for linux-xfs@oss.sgi.com; Mon, 7 Oct 2002 21:10:01 +0200 Date: Mon, 7 Oct 2002 21:10:01 +0200 Message-Id: <200210071910.g97JA1Lx002409@lab343.munich.sgi.com> Subject: TAKE - Remove leftovers of long-dead iocore methods To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Oct 7 12:10:05 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:129234a linux/fs/xfs/xfs_rw.h - 1.68 linux/fs/xfs/xfs_mount.h - 1.159 linux/fs/xfs/xfs_inode.h - 1.170 - Remove stale typedefs. From owner-linux-xfs@oss.sgi.com Mon Oct 7 12:20:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 12:20:25 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97JKMtG015780 for ; Mon, 7 Oct 2002 12:20:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA39493 for ; Mon, 7 Oct 2002 14:20:17 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA19151 for ; Mon, 7 Oct 2002 14:20:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g97JIFq07917; Mon, 7 Oct 2002 14:18:15 -0500 Message-Id: <200210071918.g97JIFq07917@stout.americas.sgi.com> Date: Mon, 7 Oct 2002 14:18:15 -0500 Subject: TAKE - Remove unused pagebuf flags X-archive-position: 847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Remove unused pagebuf flags Date: Mon Oct 7 12:19:59 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-expect The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129235a linux/fs/xfs/xfsidbg.c - 1.202 - sync up xfsidbg with pagebuf flags linux/fs/xfs/pagebuf/page_buf.c - 1.66 - Remove unused pagebuf flags Remove code that only checks those flags linux/fs/xfs/pagebuf/page_buf.h - 1.43 - Remove unused pagebuf flags, collapse flag numbers From owner-linux-xfs@oss.sgi.com Mon Oct 7 12:22:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 12:22:31 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97JMTtG016005 for ; Mon, 7 Oct 2002 12:22:29 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 MAA05022 for ; Mon, 7 Oct 2002 12:22:28 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g97JLdIx003660 for ; Mon, 7 Oct 2002 21:21:39 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g97JLcEJ003659 for linux-xfs@oss.sgi.com; Mon, 7 Oct 2002 21:21:38 +0200 Date: Mon, 7 Oct 2002 21:21:38 +0200 Message-Id: <200210071921.g97JLcEJ003659@lab343.munich.sgi.com> Subject: TAKE - Remove struct pm entirely To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs It was never defined in the Linux port.. Date: Mon Oct 7 12:21:29 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:129236a linux/fs/xfs/xfs_rw.h - 1.69 linux/fs/xfs/xfs_rw.c - 1.366 linux/fs/xfs/xfs_inode.c - 1.351 linux/fs/xfs/xfs_inode.h - 1.171 linux/fs/xfs/linux/xfs_lrw.h - 1.28 linux/fs/xfs/linux/xfs_lrw.c - 1.171 - Remove struct pm argument from several functions. From owner-linux-xfs@oss.sgi.com Mon Oct 7 15:41:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 15:42:02 -0700 (PDT) Received: from mailhub-1.iastate.edu (mailhub-1.iastate.edu [129.186.140.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97MfvtG019522 for ; Mon, 7 Oct 2002 15:41:57 -0700 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-1.iastate.edu (8.9.3/8.9.3) with SMTP id RAA24428; Mon, 7 Oct 2002 17:41:52 -0500 Received: from pircsds0.agron.iastate.edu(129.186.26.63) by mailout-1.iastate.edu via csmap id 6467; Mon, 07 Oct 2002 17:52:44 -0500 (CDT) Date: Mon, 7 Oct 2002 17:41:53 -0500 (CDT) From: Daryl Herzmann X-X-Sender: akrherz@pircsds0.agron.iastate.edu To: Simon Matter cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18-14SGI_XFS_1.2a1 oops && raid5 troubles In-Reply-To: <3DA1A482.2C3AA6CF@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akrherz@iastate.edu Precedence: bulk X-list: linux-xfs Hi Simon and others! Thanks for your help again! I physically removed hdf1 from the IDE chain and tried to xfs_repair -L and then mount the array. This produced the same error that I originally reported (using the pre-release 2.4.18-14 XFS kernel). Soo, I tried booting back into my pre-8.0 kernel, which was vanilla 2.4.19 with xfs-2.4.19-all patch dated Aug 12. Guess what, this worked. I was able to mount the array and data appeared to be sound. :) So, now I have added hdf1 back into the array and I will see if it will resync under 2.4.19-xfs . /proc/mdstat reports 2.8% completed. I have my fingers crossed! ( now 4.7% :) ) Daryl On Mon, 7 Oct 2002, Simon Matter wrote: >I don't think what you see are DMA related problems but just bad sectors >on the disks (just my own experience with IBM deathstar disks). The >problem is that after a crash the RAID resync detects all those error on >the disk which you don't find otherwise because there is no access the >the exact location where the disk failed. That's why hardware RAID >controllers like 3ware can do background surface check (or how they call >it, I don't have 3ware hardware). > >I'm using 4 disks on a Promise PDC20268 TX2 Ultra-100 controller and >had a problem recently. The problem was that I have put two disks per >channel and when one disk had a problem, it would block I/O on the >channel so the other disks was blocked too and I had a corrupt RAID5. I >rebooted, mounted, and it crashed again. I have then physically removed >the bad drive and marked it as failed disk in /etc/raidtab. Then I >recreated the RAID5 volume with mkraid -f /dev/mdx, which in fact >brought the RAID5 back and I was able to mount the XFS volume and it was >all fine. > >HTH >Simon > >> >> At this point, I am getting desperate :) So I ran xfs_repair on /dev/md0 >> and did not get any errors, so I mounted the device, again no errors. I >> then tried doing a simple 'ls -l' in the top level directory and >> immediately got this (Attached as error.txt) So I ran ksymoops on it and >> that is attached as well (ksymoops.txt) >> >> Does anybody have any ideas about how to proceed? Some other bits of >> information are >> >> 1. I am using 36 inch 80 pin cables >> 2. The eight drives are on two Promise PDC20269 TX2 Ultra-133 >> controllers >> 3. This array has been functional for over 10 months, but it has never >> experienced a crash/hard reset. >> 4. This is not the same system that I have reported raid5/XFS troubles >> before. >> >> Thanks, >> Daryl >> >> -- >> /** >> * Daryl Herzmann (akrherz@iastate.edu) >> * Program Assistant -- Iowa Environmental Mesonet >> * http://mesonet.agron.iastate.edu >> */ >> >> ------------------------------------------------------------------------ >> Name: error.txt >> error.txt Type: Plain Text (TEXT/plain) >> Encoding: BASE64 >> >> Name: ksymoops.txt >> ksymoops.txt Type: Plain Text (TEXT/plain) >> Encoding: BASE64 > -- /** * Daryl Herzmann (akrherz@iastate.edu) * Program Assistant -- Iowa Environmental Mesonet * http://mesonet.agron.iastate.edu */ From owner-linux-xfs@oss.sgi.com Mon Oct 7 17:14:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 17:14:43 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g980EatG022405 for ; Mon, 7 Oct 2002 17:14:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 RAA02013 for ; Mon, 7 Oct 2002 17:14:35 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA67439 for linux-xfs@oss.sgi.com; Tue, 8 Oct 2002 10:13:18 +1000 (EST) Date: Tue, 8 Oct 2002 10:13:18 +1000 (EST) From: Nathan Scott Message-Id: <200210080013.KAA67439@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - symlink default creat mode is 777 X-archive-position: 850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Symlinks are created by default with mode 777 now, old behavior is still accessible through sysctl through. irixsgid mount option deprecated and it too is still accessible through sysctl. Minor related cleanups. Date: Mon Oct 7 17:08:03 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129282a linux/Documentation/filesystems/xfs.txt - 1.12 linux/fs/xfs/xfsidbg.c - 1.203 linux/fs/xfs/xfs_vfsops.c - 1.388 linux/fs/xfs/xfs_clnt.h - 1.36 linux/fs/xfs/xfs_mount.h - 1.160 linux/fs/xfs/xfs_inode.c - 1.352 - Deprecate the irixsgid mount option. linux/fs/xfs/linux/xfs_globals.c - 1.36 - Remove the restricted_chown global variable here, handle this in a way thats consistent with other parameters (sgid, symlink perms). linux/fs/xfs/linux/xfs_linux.h - 1.85 - Make restricted_chown, irix_sgid_inherit and irix_symlink_mode as configurable parameters. linux/fs/xfs/linux/xfs_super.c - 1.217 - Deprecate the irixsgid mount option. Move the new code dealing with showing mount args closer to the parsing code, and also make it use the predefined mount option strings (fixes inconsistencies in quota option reporting in the process). linux/fs/xfs/linux/xfs_iops.c - 1.176 - By default we now create symlinks with mode 777, ie. the Linux way. The previous behavior can still be reached through sysctl, however. linux/fs/xfs/linux/xfs_globals.h - 1.14 - Remove the restricted_chown global variable here, handle this in a way thats consistent with other parameters (sgid, symlink perms). linux/fs/xfs/linux/xfs_sysctl.h - 1.6 linux/fs/xfs/linux/xfs_sysctl.c - 1.9 - Make restricted_chown, irix_sgid_inherit and irix_symlink_mode as configurable parameters. All default to the normal Linux behavior. From owner-linux-xfs@oss.sgi.com Mon Oct 7 17:14:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 17:14:54 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g980EptG022448 for ; Mon, 7 Oct 2002 17:14:51 -0700 Received: (qmail 6703 invoked by uid 1000); 8 Oct 2002 00:30:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Oct 2002 00:30:03 -0000 Date: Tue, 8 Oct 2002 03:30:03 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: dir hashes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi I have recently run into some performance issues with XFS and directories with lots (>1k) entries. I knew XFS was immune to this sort of problems (if I remember well only ext2/ext3 did linear search in directories and XFS/ReiserFS/JFS had hashes of some sort). Is it important to devide directories with lots of entries (some with 25k subdirectories) for XFS ? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Mon Oct 7 19:58:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 19:58:51 -0700 (PDT) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g982wjtG026095 for ; Mon, 7 Oct 2002 19:58:45 -0700 Received: (qmail 13834 invoked from network); 8 Oct 2002 02:58:37 -0000 Received: from 202-6-130-69.ip.adam.com.au (HELO adam.com.au) (202.6.130.69) by eden.adam.com.au with SMTP; 8 Oct 2002 02:58:37 -0000 Message-ID: <3DA24D3C.74D34374@adam.com.au> Date: Tue, 08 Oct 2002 12:43:00 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> <1033995657.1054.25.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs Stephen, > I definitely have old filesystems which mount without issues. I suspect > you have a kernel configuration issue and the message you are getting > is not from XFS. If XFS fails to recognize the super block it prints > this: > > XFS: bad magic number > XFS: SB validate failed > > Do you actually have xfs built into the new kernel? That is what I think is happening, I'll reboot to make sure but this is what is in my kernel configuration: CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_DMAPI=y # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set The make continues to the end so I assume that unless the XFS stuff is silently crashing (weird) it is being made. DSL -- Somewhere where I hope to find someone Still I find myself near you If I hear the words I'll go. (from the musical Martin Guerre) From owner-linux-xfs@oss.sgi.com Mon Oct 7 22:17:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 22:17:41 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g985HRtG028437 for ; Mon, 7 Oct 2002 22:17:27 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id B53371E32FF; Mon, 7 Oct 2002 21:57:09 -0700 (PDT) Date: Mon, 7 Oct 2002 21:57:09 -0700 From: Chris Wedgwood To: David Lloyd Cc: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System Message-ID: <20021008045709.GA31461@tapu.f00f.org> References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> <1033995657.1054.25.camel@laptop.americas.sgi.com> <3DA24D3C.74D34374@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA24D3C.74D34374@adam.com.au> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 12:43:00PM +0930, David Lloyd wrote: > The make continues to the end so I assume that unless the XFS stuff > is silently crashing (weird) it is being made. something like: rm arch/i386/boot/bzImage make oldconfig bzImage ls -l arch/i386/boot/bzImage to be sure. If that builds (the oldconfig will make sure the .config is sane if nothing else) and yoiu still can mount the fs, then are you able to use the same kernel to boot another fs and check the /proc/filesystems? From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:18:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:19:00 -0700 (PDT) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986IktG029370 for ; Mon, 7 Oct 2002 23:18:47 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17ynhc-00008W-00 for ; Tue, 08 Oct 2002 09:18:44 +0300 Date: Tue, 8 Oct 2002 09:18:44 +0300 To: linux-xfs@oss.sgi.com Subject: xfs_fsr broken again? Message-ID: <20021008061844.GA455@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm running a 2 days old CVS kernel, and 2 days old xfsprogs. The new xfs_fsr worked OK, before I upgraded the kernel too. After that, it just produces *lots* of lines like this: could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 I've included the strace output as an attachment. --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fsr_strace.txt" execve("/usr/sbin/xfs_fsr", ["xfs_fsr"], [/* 19 vars */]) = 0 uname({sys="Linux", node="jaenoe", ...}) = 0 brk(0) = 0x8051694 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=37266, ...}) = 0 old_mmap(NULL, 37266, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40014000 close(4) = 0 open("/lib/libhandle.so.1", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\v\0"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0644, st_size=6800, ...}) = 0 old_mmap(NULL, 9972, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4001e000 mprotect(0x40020000, 1780, PROT_NONE) = 0 old_mmap(0x40020000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 0x40020000 close(4) = 0 open("/lib/libattr.so.1", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\n\0"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0644, st_size=6436, ...}) = 0 old_mmap(NULL, 9560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40021000 mprotect(0x40023000, 1368, PROT_NONE) = 0 old_mmap(0x40023000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 0x40023000 close(4) = 0 open("/lib/libc.so.6", O_RDONLY) = 4 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\204\221"..., 1024) = 1024 fstat64(4, {st_mode=S_IFREG|0755, st_size=1145456, ...}) = 0 old_mmap(NULL, 1157888, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40024000 mprotect(0x40135000, 39680, PROT_NONE) = 0 old_mmap(0x40135000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x111000) = 0x40135000 old_mmap(0x4013b000, 15104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4013b000 close(4) = 0 munmap(0x40014000, 37266) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 time(NULL) = 1034057636 getuid32() = 0 brk(0) = 0x8051694 brk(0x8051814) = 0x8051814 brk(0x8052000) = 0x8052000 open("/etc/mtab", O_RDONLY) = 4 brk(0x8054000) = 0x8054000 fstat64(4, {st_mode=S_IFREG|0644, st_size=325, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(4, "/dev/ide/host2/bus0/target0/lun0"..., 4096) = 325 stat64("/dev/ide/host2/bus0/target0/lun0/part1", {st_mode=S_IFBLK|0660, st_rdev=makedev(33, 1), ...}) = 0 read(4, "", 4096) = 0 close(4) = 0 munmap(0x40014000, 4096) = 0 fstat64(1, {st_mode=S_IFREG|0644, st_size=2905, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 write(1, "xfs_fsr -m /etc/mtab -t 7200 -f "..., 58xfs_fsr -m /etc/mtab -t 7200 -f /var/tmp/.fsrlast_xfs ... ) = 58 lstat64("/var/tmp/.fsrlast_xfs", {st_mode=S_IFREG|0644, st_size=50, ...}) = 0 open("/var/tmp/.fsrlast_xfs", O_RDONLY|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=50, ...}) = 0 read(4, "/dev/ide/host2/bus0/target0/lun0"..., 1024) = 50 close(4) = 0 rt_sigaction(SIGABRT, {0x80494d8, [ABRT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {0x80494d8, [HUP], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x80494d8, [INT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x80494d8, [QUIT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x80494d8, [TERM], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 time(NULL) = 1034057636 fork() = 317 wait4(-1, / startino=17335143 could not pre-alloc tmp space: /.fsr/ag0/tmp317 could not pre-alloc tmp space: /.fsr/ag1/tmp317 could not pre-alloc tmp space: /.fsr/ag2/tmp317 could not pre-alloc tmp space: /.fsr/ag3/tmp317 could not pre-alloc tmp space: /.fsr/ag4/tmp317 could not pre-alloc tmp space: /.fsr/ag5/tmp317 could not pre-alloc tmp space: /.fsr/ag6/tmp317 could not pre-alloc tmp space: /.fsr/ag7/tmp317 could not pre-alloc tmp space: /.fsr/ag0/tmp317 could not pre-alloc tmp space: /.fsr/ag1/tmp317 could not pre-alloc tmp space: /.fsr/ag2/tmp317 could not pre-alloc tmp space: /.fsr/ag3/tmp317 could not pre-alloc tmp space: /.fsr/ag4/tmp317 could not pre-alloc tmp space: /.fsr/ag5/tmp317 could not pre-alloc tmp space: /.fsr/ag6/tmp317 could not pre-alloc tmp space: /.fsr/ag7/tmp317 could not pre-alloc tmp space: /.fsr/ag0/tmp317 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 317 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057638 fork() = 339 / startino=0 wait4(-1, could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 could not pre-alloc tmp space: /.fsr/ag3/tmp339 could not pre-alloc tmp space: /.fsr/ag4/tmp339 could not pre-alloc tmp space: /.fsr/ag5/tmp339 could not pre-alloc tmp space: /.fsr/ag6/tmp339 could not pre-alloc tmp space: /.fsr/ag7/tmp339 could not pre-alloc tmp space: /.fsr/ag0/tmp339 could not pre-alloc tmp space: /.fsr/ag1/tmp339 could not pre-alloc tmp space: /.fsr/ag2/tmp339 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 339 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057639 fork() = 427 / startino=0 wait4(-1, could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 could not pre-alloc tmp space: /.fsr/ag3/tmp427 could not pre-alloc tmp space: /.fsr/ag4/tmp427 could not pre-alloc tmp space: /.fsr/ag5/tmp427 could not pre-alloc tmp space: /.fsr/ag6/tmp427 could not pre-alloc tmp space: /.fsr/ag7/tmp427 could not pre-alloc tmp space: /.fsr/ag0/tmp427 could not pre-alloc tmp space: /.fsr/ag1/tmp427 could not pre-alloc tmp space: /.fsr/ag2/tmp427 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 427 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057639 fork() = 515 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 could not pre-alloc tmp space: /.fsr/ag3/tmp515 could not pre-alloc tmp space: /.fsr/ag4/tmp515 could not pre-alloc tmp space: /.fsr/ag5/tmp515 could not pre-alloc tmp space: /.fsr/ag6/tmp515 could not pre-alloc tmp space: /.fsr/ag7/tmp515 could not pre-alloc tmp space: /.fsr/ag0/tmp515 could not pre-alloc tmp space: /.fsr/ag1/tmp515 could not pre-alloc tmp space: /.fsr/ag2/tmp515 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 515 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057639 fork() = 603 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 could not pre-alloc tmp space: /.fsr/ag3/tmp603 could not pre-alloc tmp space: /.fsr/ag4/tmp603 could not pre-alloc tmp space: /.fsr/ag5/tmp603 could not pre-alloc tmp space: /.fsr/ag6/tmp603 could not pre-alloc tmp space: /.fsr/ag7/tmp603 could not pre-alloc tmp space: /.fsr/ag0/tmp603 could not pre-alloc tmp space: /.fsr/ag1/tmp603 could not pre-alloc tmp space: /.fsr/ag2/tmp603 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 603 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057640 fork() = 691 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 could not pre-alloc tmp space: /.fsr/ag3/tmp691 could not pre-alloc tmp space: /.fsr/ag4/tmp691 could not pre-alloc tmp space: /.fsr/ag5/tmp691 could not pre-alloc tmp space: /.fsr/ag6/tmp691 could not pre-alloc tmp space: /.fsr/ag7/tmp691 could not pre-alloc tmp space: /.fsr/ag0/tmp691 could not pre-alloc tmp space: /.fsr/ag1/tmp691 could not pre-alloc tmp space: /.fsr/ag2/tmp691 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 691 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057640 fork() = 779 / startino=0 wait4(-1, could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 could not pre-alloc tmp space: /.fsr/ag3/tmp779 could not pre-alloc tmp space: /.fsr/ag4/tmp779 could not pre-alloc tmp space: /.fsr/ag5/tmp779 could not pre-alloc tmp space: /.fsr/ag6/tmp779 could not pre-alloc tmp space: /.fsr/ag7/tmp779 could not pre-alloc tmp space: /.fsr/ag0/tmp779 could not pre-alloc tmp space: /.fsr/ag1/tmp779 could not pre-alloc tmp space: /.fsr/ag2/tmp779 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 779 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057640 fork() = 865 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 could not pre-alloc tmp space: /.fsr/ag3/tmp865 could not pre-alloc tmp space: /.fsr/ag4/tmp865 could not pre-alloc tmp space: /.fsr/ag5/tmp865 could not pre-alloc tmp space: /.fsr/ag6/tmp865 could not pre-alloc tmp space: /.fsr/ag7/tmp865 could not pre-alloc tmp space: /.fsr/ag0/tmp865 could not pre-alloc tmp space: /.fsr/ag1/tmp865 could not pre-alloc tmp space: /.fsr/ag2/tmp865 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 865 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057640 fork() = 951 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 could not pre-alloc tmp space: /.fsr/ag3/tmp951 could not pre-alloc tmp space: /.fsr/ag4/tmp951 could not pre-alloc tmp space: /.fsr/ag5/tmp951 could not pre-alloc tmp space: /.fsr/ag6/tmp951 could not pre-alloc tmp space: /.fsr/ag7/tmp951 could not pre-alloc tmp space: /.fsr/ag0/tmp951 could not pre-alloc tmp space: /.fsr/ag1/tmp951 could not pre-alloc tmp space: /.fsr/ag2/tmp951 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 951 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057641 fork() = 1037 wait4(-1, / startino=0 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 could not pre-alloc tmp space: /.fsr/ag3/tmp1037 could not pre-alloc tmp space: /.fsr/ag4/tmp1037 could not pre-alloc tmp space: /.fsr/ag5/tmp1037 could not pre-alloc tmp space: /.fsr/ag6/tmp1037 could not pre-alloc tmp space: /.fsr/ag7/tmp1037 could not pre-alloc tmp space: /.fsr/ag0/tmp1037 could not pre-alloc tmp space: /.fsr/ag1/tmp1037 could not pre-alloc tmp space: /.fsr/ag2/tmp1037 [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 1037 --- SIGCHLD (Child exited) --- close(4) = -1 EBADF (Bad file descriptor) time(NULL) = 1034057641 write(1, "Completed all 10 passes\n", 24Completed all 10 passes ) = 24 time(NULL) = 1034057641 unlink("/var/tmp/.fsrlast_xfs") = 0 open("/var/tmp/.fsrlast_xfs", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4 munmap(0x40014000, 4096) = 0 _exit(0) = ? --VS++wcV0S1rZb1Fb-- From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:34:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:34:08 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986Y6tG029873 for ; Mon, 7 Oct 2002 23:34:06 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1D50C818; Mon, 7 Oct 2002 23:27:10 -0700 (PDT) Date: Mon, 7 Oct 2002 23:27:10 -0700 From: Chris Wedgwood To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008062710.GA32027@tapu.f00f.org> References: <20021008061844.GA455@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021008061844.GA455@psychedelic.baana.suomi.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 855 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 09:18:44AM +0300, Juha K Kallio wrote: > I'm running a 2 days old CVS kernel, and 2 days old xfsprogs. The > new xfs_fsr worked OK, before I upgraded the kernel too. After that, > it just produces *lots* of lines like this: What version of xfs_fsr do youi have? (xfs_fsr -v). What kernel version (dmesg|grep ^SGI\ XFS)? > could not pre-alloc tmp space: /.fsr/ag1/tmp427 This normally comes from a non-root user trying tro reserve space. The trace seems to indicate yoiu are indeed root, so I wonder if you have an old xfs_fsr somehow which setuid's to the file owner. > I've included the strace output as an attachment. You actually need 'strace -f' to follow forks. You could also try something like: strace -f -otrace.log xfs_fsr -v -d /path/to/fragmented.file --cw From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:36:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:36:03 -0700 (PDT) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986a0tG029983 for ; Mon, 7 Oct 2002 23:36:01 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17ynyH-0000D7-00 for ; Tue, 08 Oct 2002 09:35:57 +0300 Date: Tue, 8 Oct 2002 09:35:56 +0300 To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008063556.GA684@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs I am running it as root, and setuid bit is not set. Running as non-root comes with this: could not create tmpdir: //.fsr: Permission denied. BTW, what's that double slash there? bunnyh@jaenoe:~ > /usr/sbin/xfs_fsr -V xfs_fsr version 2.2.0 bunnyh@jaenoe:~ > dmesg|grep ^SGI\ XFS SGI XFS CVS-10/07/02:05 with no debug enabled From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:36:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:36:52 -0700 (PDT) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986altG030214 for ; Mon, 7 Oct 2002 23:36:48 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17ynz4-0000DC-00 for ; Tue, 08 Oct 2002 09:36:46 +0300 Date: Tue, 8 Oct 2002 09:36:46 +0300 To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008063646.GB684@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline And here's the strace, sine I forgot that in the last post ;) --OgqxwSJOaUobr8KG Content-Type: application/octet-stream Content-Disposition: attachment; filename="trace.log.gz" Content-Transfer-Encoding: base64 H4sICIR8oj0AA3RyYWNlLmxvZwDsnWtz20ayQL/fX4Hyhy1py7Ywj55HarW3 HFvOusqxU7Zzk63NlooiqZg3kugSKcfe5P73OwOC4gMYYpoYkZDdSSWWpQaF V+P0AJjTmgnIsuGnYf/j8ODB0c3k+mhyNro6+nQ+OT2fXD94mP3rweLrB48+ Fv8f+P8fPfi3++nRXzNms4+960n216N/H2bHWf5fuvjQm6ve5fDgj8nnyfGD l6Orm09uoavxYHj84H97w6vx0P318ePH/7e8yNn1bwf5YbbhHxf7yeTAlJXl MuOLwenlZe/DwasfX758mMncqofZD29evzt9c/Lk2Z/FVz+9efHu5GH2/ZMf Tn948+J/nrw7+dN//eTV61f//P71j28fZo/YwywvVuWTzHMm8ny+TuMPwyu3 Z4bT/tHF4PFk/PjD9fBi3PO74PXpm2evX738p1/uEctOXr0+efUuO3g1ziY3 /ffZ+ehimI2vs8Hoetifjq8/H4Y+st/rvx+ufeB8+84n095UyQP5MPtjMj29 9Hvw7emL529OvvszV9J92313MvrP8FhorlR1p67toDLqdg+t7Ba3/1b2g1zs h/7FeDI8kBuOztKvnG3gxejM//e+dzW4GPrtZIFtvB72Bn4DH/zCtD55+fwX VvybV/4V5X/znwme//Lxl/yB2+aHGcu59J/q/0TvPGXyvHHfWat55eQ6+fnk 6cadOFzsxMsP1+OpOxkOip9w9wP3S5k2efmp7oQ8qf39y/GYU/z5i59Pns1W 6BNzS9+uVfFZrQ9tbzq9vpMDy2X+y1WaAytFc1JYUDn6wHIWPLBidmCFMnEH ViQ8sCLFge37o6pWjmqSw5rLXzhn2x1WDbA4rIxJkNB8ZBkDbYzBH1wZOLju O8XBElbFpe18AS5Bb3d42fIBnn1c/S86m512wHKJ+kUbaTj72C3OqMubq9sz vCBJCZ/DmtjRuD+9OHARb189e/ru5em779+cvnvx/cm3T966lf7jW2HcB7hz dDyZZqPJ6Nds1O9dja+yYf/9uHIKTEeu8PCHP7ia/qQTMgd3ZohyoV+H05vR QPCDDQvNf8FFeZq6GmjtRH324s3aiTpL6hSVTrFM8T3D6o/AfBn38/VleHEK hZfhtRXP5bR3tnoRKJepfL5s+PyldEJUNBwaEzxNwbe0ercXt6PB8OPRaDA8 eu/OOn50djPJj6a9a3ei5EcXN1clnPzv95/j1rX8gN+vR9PhAfOf4Lakdz0d XY2PHc4eeCIclqefWN3ZSzv5z9enL5+8+e7k+YuXJ4dFMKwkCfhrQj9nfTAe L/mns/Pz8749yw9rLucbP1etfK56WBwp5T9XPpyffTw/XDn1by57k82nrovl fH4J+M0Vv241jh7PBhC51vpwPbou9qj3a16JD8cyRCxHxApErETEAiJWIWL1 htjyyHEecYFbOiPcmeaukwrmZ9qgp/p1Z9rGy4VeS33dodSHtdTXLVJ/hkeN xyPcFoCHdbHlPnZ1iNvJw8vR1fl4bT9H7mO5vI+bBzx3t4fn2zgdT3sX3/iv bibDQfHF+fVw+M3qHgYu7ngP34JMNYBMLTamej0+W2QJm12P50fFnTofRoNw cVHEusgKQzw8mBEFPszKqpvbA/75qh+5S/y5cT4pC5fz0+nnD+40+ARGKhDS jW3PT8+Wqhb3t4tx/7fJsSspuWWm+I4/PMdGu1FrEe/vckyOldsxUhYB50UA WMOtsf4b/j7QxfDqmAOsnGuti6iVrBjfXE0n6xef5Z00+22ms1nh1uzB9Xjs Dk92lJVfXP+e5ZkrHYrrkf/ealpwlWxfzvLKJM+rWY7oWT3hc4SdL3IkX61Z zscuCRuKYhc5L1t+742m8sDv1exvN1fno6vR5P1w4Lfs7z5Cub0yr+nzT2JY u23lL1crK9rPuUMeV7fFlRwsIU/VZGc2/DQduvPvmGduXHI66X10I9Rsevlh dryAFRcxVi5enrfzOufIxfktKk/en964Su2pO7HeuT9Pfn760v3hjuLJ03fL FZxbN6WKk8CUn3pzdTG6+q3ucw8DG2tmRyX3R2V4e1SszQMb++zk2x+/+8al kj+NuL9gZGcXk/+cDkbjYz+6nW2sMn6t1Hy1bi+sw4YL6/w22erqyZy71eO9 xeopWayev+H6w8mb77OD1x+G173pyI0Gr8bTzP3lcjSdDgeHlfXvj28uBrOg 6+Gj3oW7tvljlE0+9PrDb7KjMrlscQfLlotHJ4aLPR1+Gk3dGRkOPs7+uzx7 /+Z+2ewUduk/ubkcDv6e/eunF89PfnbXkWcHk8PsL3/JfvJ/e/vuybsf3/rv HLuUB/i32xcPs9n4diUhHj16lL198d3Tf7x8lh08fT9yG+tXyO0K/6MtABoT 64/Dt0+ePc8Ovu0NZve8B8NJ/3r0YTq+Ply5CsTVk3cbuwNaS82I1kRronWR I/OUaqC1RtBaI2ita7ITQWu9TmuWgta6SmsWorVG0FoHaS2E5rCgteBaVWmt F7T2o5xNtFbzx0c6Ja11O1prRGLovdF6nhBE607QWpmcaE20JloXOVIcUoNg sUGw2NTkHoLFZp3FPAWLTZXFPMRig2CxCY+cDXeDxYaRs9li5GxSsti0Y7FB nPYGx+IocC7KzS0xbVaS96slMMVS7H2O3UEFyUFrOXu8ny+AwRavO1AJSSXk 11NC2rgbPhZRZFpEkWlr0zNQZpZFpiiKTFEuvlpkihRFpq0WmSJUZFpEkWnD N3xyIdlSkWlUTZFpl4rM84Yi87zMB5uyyLTtikyLSAy7txs+84To+g2fnaDS MEWoJFQSKl2SyDwKlTKPR6WPjUWlj61Jz1hU+sVXUSkToNJ/6joqZQCVi41t RuXqxq7ej+HMmCVU5tJUUOkXv0XloAGVg1k+rK1eO1Surj8alX7x2MTwsftB 5W1CdB2V93m0qgyn0SohmBBcXHH8kwU3UIoHLEMAltUmXzRg2TpgIQVgWRWw EAIsQwCWhceiOldLgBXKVF8+8IvfvnzAGl4+KCderq1eS8CydoBlCMCyDj7w KDLhKxiBugwEwh/hj/Dnk55Xrh61I1COACRHAJLXpmc0IPk6IFUKQPIqIFUI kBwBSB4EpLsg2KV36RnnNSNQvjQCPWsYgZYzttdWryUgeTtAcgQg+d5GoPOE +JJGoLvAquFGE1YJq4RVfxWZz1ZtwKpAYFUgsCpq0zMaq2IdqzoFVkUVqzqE VYHAqghi1QBoscCqYZZXsSqWxp39hnFnv8SqSIlV0Q6rAoFVsTeszhPiS8Iq xXayFBHKWipFqBShUqS48s5NTQ2liESUIhJRisja9IwuReRdzJb3nxo7W36x sRGliAyP8AVXommEL7cY4cuUpYhsV4pIRCki91aKzBPiSypFdoFVnZfz2gmr hNWvHqs+SSQgoAkIaNYnXzQ04S4mrftPjZ20vtjYCGhC+MUsabVsmCjnF8dO lFtbvZbQhHbQRJz2PrZ7z423cd/dv+fGPgPpuTHhj/BXJL1XTkmEYU0iDGuy Ylgrki8afxXDWop54rLGsBaaJy4RhjUZNqwxIbRuGjOqLcaMKQ1rsp1hTSIM axJpWNsN/tT+8deFG7sUS7FfS+wuHIJKcUvlJpWbVG56yMZJBCVCIigREkFZ lQj69IwuSCsSwRRzymWNRDA0p1wiJIIyLBHkuVaNE+X0FhPlUkoEZTuJoERI BOXeJIKSJIIUS7EUS7EUS7EUS7EUS7EUS7EUex9id/HEnucCyrab8+H5sfuS bqHSLdSv8Bbq/JA23EJFuN8lwv0uK+73WXrW30Mtb6EW3cFBlovfgWusxv0e dI0h3O8y7H5nQsm86Zm+2eKZfkr3u2znfpcI97tEut8T3kKdJ8SXdAt1R1jV mrBKWCWsuqtInO1aImzXEmG7lhXb9Sw9Y7FasV0nMYzV2K6DhjGE7VqGbdfM GGGXsKpEDVaXbdcNM71hPtM7pe1atrNdS4TtWu7Ndi3Jdr2Si4YRKgmVhErt fmEUKgFhuwaE7RoqtutZekaiEiq26xSuMaixXYdcY4CwXcMG27XQVjW8xANb 2K4hpe0a2tmuAWG7hr3Zrm8TglA5y0VOqCRUEirdlYHFoRLhrQaEtxoq3upZ esaisuKtTuEPgxpvdcgfBghvNYS91Uxb2TSqBIYfVUJKbzW081YDwlsNSG91 QlSye4LK7t2slRIIq4RVwqq7isTZrgFhuwaE7RoqtutZesZitWK7TuHCghrb dciFBQjbNWyyXSvd5MKCLWzXkNJ2De1s14CwXcPebNdAtutNK7gBqyAZ3dgl rBJW/VXET3IEhMsaEC5rqLisZ8kXC82KyzqFCwtqXNYhFxYgXNYQdlm7n+Wm CZpiC2imdFlDO5c1IFzWgHRZ70QGAuJ+oZJiKXbXpZPOuaUb/VQ6UenkgVHU KAj3NiDc21B1bxfJF1s6VdzbKTxqUOPeDnnUAOHehrB7mysFvEEjChKvEYWU 7m1o594GhHsbkO7t3ZROciV5qXSiWIqlWIqlWIqlWIqlWIqlWIqlWIqlWIql WIqlWIql2L3EQhl7lz0AtFGMlaoNfliGs/k7e/SolB6Vfk2PSn2SACAela6u xuZHpaHky3oX/ih9zs5vLi4+Z4Ph+XXv1/nRKJ6+zRefPVHb8EAtu8snaqzy PK0Dbfm6cJ3uQuwOWGGEMcZaYgWxgljBQFWuobUTfRANDAHRwBAqDQzL9Kx9 86Z88QaKF2+gXDy97BBqGhiGZIeAaGAImxoYmtw2vbO8RQNDSNnAENo1MARE A0NANjBMONFnnhA00aduBTdi1cqcsEpYJawyiGvDBog2bIBowwaVNmxlekZi tdKGLYXsEGrasIVkh4BowwbhNmySqZwtsOpPgCpWl9qwKb4Zq8XPq6vXEqvt 2rABog0b7K0NG3yJbdh2g1Wbc0FYJawSVhkUF2yEeB8Q4n2oiPfL5IuEZkW8 n0R7WCPeD2oPEeJ9CIv3ubTL82frJ4GYLSaBpBTvQzvxPiDE+4AU7+9mEojZ Pyp3hT8hCX+EP8IfgziFPiAU+oBQ6ENFoV+mZyQgKwr9JLLDGoV+UHaIUOjD BoW+yCVvullrt7hZm1KhD+0U+oBQ6MPeFPpwXxT6X8+zVcs5vYdDuCZca3a7 zZtxrRAaf4XQ+KuKxr9Mzzhcq4rGP4VEUdVo/EMSRYXQ+KsNGn9meZPGX22h 8VcpNf6qncZfITT+am8a/9uE6Dqud4ZKQ6gkVBIqmYrT+CuExl8hNP6qovEv 0zMSlRWNfwp1oqrR+IfUiQqh8VcbNP5cqjV34mxjdXGO6/nic1RqtRmVxc+r q9cSle00/gqh8V/eVpANZYFcbOue8Hpf1P87wyu95Ut4Jby6K0Oczl8hdP4K ofNXFZ1/mZ6ReK3o/FPo9VSNzj+k11MInb/aoPMXBnTDjWO1hc5fpdT5q3Y6 f4XQ+au96fzVfdH57wqVgncNlUoRKgmVu0eliEMlQuKvEBJ/VZH4l+kZicqK xF+kQGWNxF+EUImQ+KuwxF8KlauGN3eVwL+5q1JK/FU7ib9CSPwVUuKfEJXi nqCyC89YuxC7o5IBTOcm+1DJQCXDPkqGuZC7oWRAyOsVQl6vKvL6Mj0jS4aK vD7FHFpVI68PzaFVCHm9Csvr3YGHpjm0Sm4xuk4pr1ft5PUKIa9XSHl9wpJh nhBdLxl2hEpFo2tCJaHSXxkK4gAChIAAYSj5IkEIdzHr1X9q7KzXxcZGgBDC LzxJYLLphSfY4oUnSAlCaAdCxGnvYzs3gUfdM+vUrlCpOvf2MKGSULkPVHoR jUJ4lxTCu6TqvEs++SJRWfEupZjrqmq8S6G5rgrhXVIbvEvc2qapPGoL75JK 6V1S7bxLCuFdUkjv0m5QqQiVNdmqc0WoJFQSKpnyOaUQLiWFcCmpOpeST75I VFZcSilmvaoal1Jo1qtCuJRU2KXEuDKiCZV6C1SmdCmpdi4lhXApKaRLaTeo 1PcLlfctdidot3kuaBRMaCe0uwuaqVwZa5+tIpxQCuGEUjVOqCI9I+FfcUIl mUNb44QKzqFFOKFU2Anl4K9kE/zNFvBP6YRS7ZxQCuGEUkgnVMJnq/OE6Pqz 1XuOYM7omS0hmBDsrjhx1imFsE4phHVK1VinivSMRHDFOpVkbm6NdSo4Nxdh nVIbrFPKvwTcgOAtrFMqpXVKtbNOKYR1Su3NOqW+ROvUrrAqgLBKWCWsMj0P 34xVjbBDaYQdStfYoYr0jMOqrtihUszJ1TV2qNCcXI2wQ+mwHYoB5E1Y1Tke qzqlHUq3s0NphB1K780OdZsQXcfqzlBJz3cJlYRKd955sY1GuJ80wv2ka9xP RfJFgrDifkox41bXuJ9CM241wv2kN7ifIJdN02c02wKEKd1Pup37SSPcTxrp cdrJ813NviL80TNQwh/hz513/rzXCDeTRriZdI2bqUi+SPxV3EwpZo/qGjdT aPaoRriZ9AY3EzeQN+FvCzeTTulm0u3cTBrhZtJIN9Nu8Me/Ivx1zg1M+CP8 7QN/cUYmjTAyaYSRSdcYmYr0jARkxciUYlaprjEyhWaVaoSRSYeNTJxzxRtm lWqBn1WqUxqZdDsjk0YYmfTejEz6vhiZdobKznl+CZWEyn2gMs5EpBEmIo0w EekaE1GRnpGorJiIUswq1TUmotCsUo0wEemwiUjkuV7uoGpUtYOqXjYRnTeg 8rxEZUoTkW5nItIIE5Hem4lIk4loNRclSfsIlYRKd94VxAEECAEBwlDyRYIQ 7mLOqP/U2Dmji42NACFseKYobePLNbDFTVVICUJoB0LEae9ju3dTtQMmop3h j26qEv4If/6885cjhF1II+xCusYuVCRfJP4qdqEUsyZ1jV0oNGtSI+xCeoNd yGX38jNFJWrwt2wX6jfgr1/iL6VdSLezC2mEXUh30S6kO2AX2hn+6EYp4Y/w 5847n1MaYQzSCGOQrjEGFckXib+KMSjFjEVdYwwKzVjUCGOQDhuDOLOsqfG2 1ls8MUxpDNLtjEEaYQzSXTQG6Q4Yg3aFP6Ap/YQ/wp877+KsOhph1dEIq46u teq49IwEZMWqk2TuYY1VJzj3EGHV0RusOlav2Gdrx4dmi/FhSquObmfV0Qir jt6bVUffF6vOzlApCJWESkIl03H2G42w32iE/UbX229ARKKyYr9JMjuxxn4T nJ2IsN/osP2Gcyaaeppou8VYMqX9Rrez32iE/UbvzX6j74v9ZmeoJKMNoZJQ qZnx4QbhqzEIX42p99VApK/GVHw1KeYpmhpfTWieokH4akzYV8NXnylyCdV3 S82yr2bYAMLh7Gw3KX01pp2vxiB8NQbpq9nJTVWDQdp9xx9Zagh/hD+X9N7N YRCWGoOw1Jh6Sw1EWmpMxVKTYhaiqbHUhGYhGoSlxmyw1AjROE3fbGGpMSkt NaadpcYgLDWmi5Ya0wFLTRe6hVAsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIs xVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIsxVIs xe46FsrYO5xSyJS2SuVllwpxOAtn845XNKWQphR+TVMK/VRag+j8axCdf02l 8+88+ermFJZTCotjAapcPH23JlPT+TfUrckgOv+acOdfriQzTTPq+RYz6lN2 /jXtOv8aROdf08XOv6YDnX+7iEotCJWESkIlM/68N4gewAbRA9hUegDPky8O lZUewCn6OZmaHsChfk4G0QPYhHsAMyFV4+x7scXs+5Q9gE27HsAG0QPYIHsA 7waV4n6hkmK/iFG7NVJTKUKlCJUiJq4Ls0F0YTaILsym0oV5np5xxUqlC3OK 7lumpgtzqPuWQXRhNuEuzO7A88ZiRW5RrKTswmzadWE2iC7MZm9dmA11YV7L xXknEkIlofKrRiXEoRIQqAQEKoPpGYdKuItOXf5TYzt1LTY2ApUQRiW3uhGV sAUqISUqoR0qEYnhY/eESrgnqOzCyJZiKZZiKZZiKZZiKZZiKZZi78kTI2Ol MIxug9FtMLoNZoq7SQpxk0shbnKpUPLF3eRSd9Ft139qbLfdxcZG3ORSG29y saabXGqLm1yrq9fyJpdqd5NLIW5yqS6+vKLo1hbFUizFUizFUizFdm/oqnMj jDE0dKWhKw1djc8poxFDV40YuupQ8sUNXfX60FWkGLrq6tBVhIautxsbMXTV 4SmKOVd6aeiqRM3QVS8NXfsNQ9d+OXRdXb2WQ1fdbuiqEUNX3cWhq15J3s4P XXeESpCcpigSKgmVzJjKlab2ZUeDgKlBwNSE0jMOpmYdpjIFTE0VpjIEU4OA qdkwiTFntuk+sNniPrBJCVPTDqYGAVOzt5cd5wlBLztSLMV2sHxjRgDv2lwV yKl8o/Jt9+VbAVaLKM4sojizoeSLK87senEGKYozWy3OIFScWURxZsPFmbR5 Y3FmtyjObMrizLYrziyiOLNdvNNh91+S7Q5/gvBH+CP82bxy9ai7e2HzeED6 2FhA+tj69IwCpF88va3Qf2qsrXCxsc2AXN3YtbfYhGwCpF8cC8i11WsHyNX1 RwPSLx6bGD52P3cvbhOC7l5QLMVS7Bdxx0cIV3MqKnmp5KWS17K4kpchSl6G KHlZKD3jSl52F9ZR/6mx1tHFxkaUvCxc8irBRFPJy7YoeVnKkpe1K3kZouRl eyt55wnR9ZJ3d6js2mughEpC5T5QyeNQiehlYRG9LGy1l0WZnnGorPSySOG8 tDW9LELOS4voZWHDvSwE0xKWelkYVe1lYZd7WZw3oPK8RGXKXha2XS8Li+hl YZG9LBKikhMq13LREioJlYRKK+JQiehlYRG9LGy1l0WZnnGorPSySOG8tDW9 LELOS4voZWE39bKA3DSNKrfoZWFT9rKw7XpZWEQvC4vsZZEQlYJQuZqLomte HEIloXIfqIzrpGARnRQsopOCrXZSKNMzDpWVTgopzDm2ppNCyJxjEZ0U7IZO Cg5isgmVW3RSsCk7Kdh2nRQsopOC3VsnBUudFNZzkd5OJ1QSKpmN66RgAYFK QKAymJ5xqIS7mKnvPzV2pv5iYyNQCRtez1Oc/397Z9Abqw1F4b+C3urtyjUY xtl1UVWV2r7uu6jy8iZqqnQqTROp+fcFw0wYbMO9g8N4krPqk3pAMOH6XIz9 nTmr1GdYpY5plXqZVQoKo9VeyCqvJUlhPavESnZYJaySjHUcAW3VCGirxqWt 9sXHM0KHthpjl73x0FZDu+yNgLZqpmiruqzmjPAM2qqJSVs1y2irRkBbNSnS Vk0CtNX17K+E/cH+YH+mrSkjILYZAbHNeIhtXfHx7M8htsXYx2w8xLbQPmYj ILaZMLGNSspnp0zrM+wvJrHNLCO2GQGxzaRIbDMJENvWsz8N+4P9wf4Mj8Jm BBQ2I6CwGQ+FrStPnkE6FLYo+5g9FLbgPmYBhc2EKWyq3qjBpg5Vas9K1SGF bTtjkNveIGNS2MwyCpsRUNjMxShs5loobOtZZQ2rhFXCKo3hWaWAiWUETCzj YWJ15cmzSoeJFWX/o4eJFdz/KGBimQkmlqrM7P7HM5hYJiYTyyxjYhkBE8sI mVgRrdLAKk9rscTyG1glrFIdf7VJq2xkbKu0WqZVWq2/PDlWaQ+Pvv/RnpW5 /3Fws7NWObrZ0bSrnpt2tYcLrXJ8eYuscnT9Uqu0hzMLw2ovYpWvBQGrPNQi lt/AKmGVKmdRdRqZwCr5VB2r9Zcnzyodqk6E/Y/2rMz9j4ObZVhlmKpTUF2p aVSAPVyIChhf3kKrXETVsYezrfJSVJ3XgkjdKlOA4EELLbTQQgsttNBCCy20 0EILLbTQQgsttNBCC+1baXWvfcNPxkpTVZUGQSz4ZIxPxipX7Qc6PjveageX Mf1B2GHHH4qP90HYYcdHoPzZszIpf4ObZXwQDrPjm3I3M0Bce7h47VREdvzo +uUfhPnseKtNbcuqrYRB8b7XFVO2AnUO+4P9wf5UziLGNzKBQfKJ8VbrL0+e QTrE+AhsP3tWJttvcLMMgwwT402tdP5qkKZUuWuQA2J8NbNiqjqsmIpIjB9d v9wg+cR4q73QiqlrIcan8LZ6bdp12gvTujnaC7QXaC9yFmW/kQnaCz5l32r9 5clrLxzKfgRioj0rk5g4uFlGezFB2a/Koh68f1eF5/17SNm/m3n/vuvbi4iU /dH1y9sLPmXfai/UXlwLZT8Fu4b2XbRDzXCL0CG0Q2iHmk6lNR8taHa0oNkJ Fh+v2dFvwMe0Z2XyMQc3y2h2dLjZKfLN7EZtfcbHBh2z2dHLmh3+Y2+16X1s 0JdvcdazP+ChYX+wP5Vbn+GnI1gt2/6cdIRD8fHsz0lHiEC/tGdl0i8HN8uw v4l0hLqp1rl3/eqMd/2I6Qij65fbHz8dwWrTs7+PkY7QVyDS2WF/sD+V1+1w xE9HsFq2/TnpCIfi49mfk44QgWhpz8okWg5ulmF/4XQEOyK82p+ui9K1v0E6 QlXNfEmvevuLmI4wun65/fHTEaw2PftLIB0hhQlYaKGFFlpooYUWWmihhRZa aKF9r9pVpp01lRvCFi9MO2PaWeV2ypOfOWi17GlnJ3PwUHy8aWcnczBKOoQn czCYDsHPHBzd7HiHs54JUrKHixcdRcwcHF2/fNqZnzlotelNO29Oivf9fnW1 FbiB/cH+YH+5Hbr4OYJWy7Y/J0fwUHw8+3NyBKMkPnhyBIOJD/wcwdHNnkbu NndcT0fu2sOFkbvjy1tof4tyBO3hbPsT5giuY3/mI9kfFh3B/mB/itrhiATZ gCTIBiQnG/BQfCz7IycbMAbfijzZgCG+FQmyAWkiG7BQam7LCZ2RDUgxswFp WTYgCbIBSZgNuIr9kcTSrt3+FAAUsD/YnyJqhyNB3h8J8v7Iyfs7FB/P/py8 vxj0KvLk/YXoVSTI+6Nw3h/p5uVizv7oDPuLmfdHy/L+SJD3R8K8v3Xsjz6S /SEQF/YH+1OknNHDx18iAf+YBPxj8vCPu/LkGaTDP47BXyIP/zjEXyIB/5gm +cc0a5Bn8I8pJv+YlvGPScA/JiH/OB5/6VgQH5W/tJIF10WB5TewYFiwIh5h mQSEZRIQlslDWO7Kk2fBDmE5BhWIPITlEBWIBIRlChOWqfmBihksAhVyLALF JCzTMsIyCQjLdDHCMl0LYXktq9zUmKyFVcIqFZXtwCRgAZOABUweFnBXfDwj dFjAMfhA5GEBh/hAJGABU5gFrDblMGrAu1SHSvlSHYrJAqZlLGASsIBJyAJe Z7K2vLz9pbBZBFpo12/JalOU+ICAlgwtmaKWWExa0JJpQUsWLL5jS1ZMtWT6 LZhV7Vm5zKrXm2W0ZDo8N0E5meH3gbzqbra2T3B9OPzQktVquiWz/9+9vIUt mV7WkvEfe6tNryVLgFicggW/Z+0q7YUp6rrQaC/QXqC9IOvjAiI0CYjQ5CFC d8XHm/FxiNAx9iaThwgd2ptMAiI0TRChS8pnV6dXZ6w+iEmEpmVEaBIQoSlF IjQlQIRO0iprbOSCVcIqFbX0aBLQo0lAjyYPPborPp5VOvToGPuYyUOPDu1j JgE9msL0aKryopqzyvoMq4xJj6Zl9GgS0KMpRXo0JUCPXs3+NqmtDShK2B/s b3372zijh3cZnYBzRQLOFXk4V1158gzS4VxF2ens4VwFdzoLOFc0wbkydTmX LkSbM5bRxeRc0TLOFQk4VyTkXEVcRreReO6VvFWmoF3D2k3RNJp5aivkYe2w 9ktYu+FZ+wnDK3TWflgWMLzIZXj15ZndPrZ/yJfs/vnx8aUZ4O73t/3fi6xb UH945wATBrDcAcgZ/80HH//XGqfLIrW1QBinMU5fYJxWOWucVjl/nFYC2JRy YVN9ebJewZQDm4qxmVh5YFOhzcRKAJtSYdhUWVX5gLVY6lw7r2BqAJuqipmE u6J7BVNM2NRBa2un+bN9+nL3lGU6o+qmLG4Kk/11u939s81++/6XP553D//9 3pdOc532Z7P/OLnFzbKTHC9ku2uewuZZzp7/3e6zr8+73cuf2deX7OcvP/70 6+fnh9MaJq3JuQzZKdr/9qe4f9o/7+5un7bNYND8qvZXq/L7cWl2Wusb8y+X o7/IbHWcVNJt2fjit+5BK7ebrX0EfA9XXzzZ121z39sbld3eP233N5Q1o/kP 2cOuv+XC3nDRH859P1ZHElhwJMgidEf5uDs6jlXojt60OyrrIjXOdGnQHaE7 Wr87smZCgt5HQBpTLmmsLz7WO6oi2Ttq/M94zuurSgBHlcJsI7TQQgsttNBC Cy200EILLbTQQgsttNCmp93//e1h//nTd8cdjMdPne6k3VhLAq0SaAuBthRo tUBbCbQ1V+voTrXdpGjlEzla3qe4/wE7MeK+kDYDAA== --OgqxwSJOaUobr8KG-- From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:42:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:42:58 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986gutG031198 for ; Mon, 7 Oct 2002 23:42:56 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id C619A1E3315; Mon, 7 Oct 2002 23:42:55 -0700 (PDT) Date: Mon, 7 Oct 2002 23:42:55 -0700 From: Chris Wedgwood To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008064255.GA32219@tapu.f00f.org> References: <20021008063646.GB684@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021008063646.GB684@psychedelic.baana.suomi.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 09:36:46AM +0300, Juha K Kallio wrote: > And here's the strace, sine I forgot that in the last post ;) It looks very much like a trace of xfs_fsr before eric committed the fix a few days ago. I hate to nag, but please verify the code you are running in indeed recent. --cw From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:49:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:49:32 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986nUtG031806 for ; Mon, 7 Oct 2002 23:49:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 XAA04323 for ; Mon, 7 Oct 2002 23:49:29 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13591; Tue, 8 Oct 2002 16:48:10 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) with ESMTP id g986lhci001630; Tue, 8 Oct 2002 16:47:43 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g986lg1b001628; Tue, 8 Oct 2002 16:47:42 +1000 Date: Tue, 8 Oct 2002 16:47:42 +1000 From: Nathan Scott To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008064742.GA634@frodo> References: <20021008061844.GA455@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021008061844.GA455@psychedelic.baana.suomi.net> User-Agent: Mutt/1.4i X-archive-position: 859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 09:18:44AM +0300, Juha K Kallio wrote: > I'm running a 2 days old CVS kernel, and 2 days old xfsprogs. The new > xfs_fsr worked OK, before I upgraded the kernel too. After that, it just > produces *lots* of lines like this: > could not pre-alloc tmp space: /.fsr/ag1/tmp427 > could not pre-alloc tmp space: /.fsr/ag2/tmp427 > could not pre-alloc tmp space: /.fsr/ag3/tmp427 Do you have free space on the filesystem (df)? xfs_fsr has to preallocate space for the new, improved file layout to occupy, so if you're out of space these errors kinda make sense... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 7 23:57:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Oct 2002 23:57:28 -0700 (PDT) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g986vOtG032364 for ; Mon, 7 Oct 2002 23:57:25 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17yoIx-0000I8-00 for ; Tue, 08 Oct 2002 09:57:19 +0300 Date: Tue, 8 Oct 2002 09:57:19 +0300 To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008065719.GA999@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs Sorry, I just noticed that xfs_fsr was in xfsdump, not in xfsprogs. So that should be it. But I ran into another problem when updating everything: I made a Debian package of attr with debuild, and it made a very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be missing from /usr/lib. From owner-linux-xfs@oss.sgi.com Tue Oct 8 00:43:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 00:43:22 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g987hJtG001227 for ; Tue, 8 Oct 2002 00:43:20 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g987hGI22027; Tue, 8 Oct 2002 09:43:16 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yp1Q-0001B1-00; Tue, 08 Oct 2002 09:43:16 +0200 Date: Tue, 8 Oct 2002 09:43:16 +0200 From: Christian Guggenberger To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008094316.A4351@pc9391.uni-regensburg.de> References: <20021008065719.GA999@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20021008065719.GA999@psychedelic.baana.suomi.net>; from bunnyh@psychedelic.baana.suomi.net on Tue, Oct 08, 2002 at 08:57:19 +0200 X-Mailer: Balsa 1.2.4 Lines: 20 X-archive-position: 861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 08 Oct 2002 08:57:19 Juha K Kallio wrote: > Sorry, I just noticed that xfs_fsr was in xfsdump, not in xfsprogs. So > that should be it. But I ran into another problem when updating > everything: I made a Debian package of attr with debuild, and it made a > very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be > missing from /usr/lib. > Hi, I have the same problems here on my debian/unstable box. According to Nathan Scott the builds are fine on his box... maybe Nathan should check again?! But I can build proper packages on a debian woody system.... But you can use the latest xfsprogs, xfsdump and attr binary packages from debian/unstable, they contain the fixes Eric checked in last week. Christian From owner-linux-xfs@oss.sgi.com Tue Oct 8 00:50:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 00:51:00 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g987owtG001705 for ; Tue, 8 Oct 2002 00:50:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 AAA06254 for ; Tue, 8 Oct 2002 00:50:56 -0700 (PDT) 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 RAA14680; Tue, 8 Oct 2002 17:49:20 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA57955; Tue, 8 Oct 2002 17:49:19 +1000 (EST) Date: Tue, 8 Oct 2002 17:49:18 +1000 From: Nathan Scott To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008174918.A258148@wobbly.melbourne.sgi.com> References: <20021008065719.GA999@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021008065719.GA999@psychedelic.baana.suomi.net>; from bunnyh@psychedelic.baana.suomi.net on Tue, Oct 08, 2002 at 09:57:19AM +0300 X-archive-position: 862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 09:57:19AM +0300, Juha K Kallio wrote: > ... that should be it. But I ran into another problem when updating > everything: I made a Debian package of attr with debuild, and it made a > very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be > missing from /usr/lib. Hmmm... you're the second person to report that. No idea why that happens, it works fine for me (TM). Maybe you can investigate and get back to me with some build logs, configure files, etc, & maybe even an explanation. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 8 01:06:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 01:06:26 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9886ItG002505 for ; Tue, 8 Oct 2002 01:06:18 -0700 Received: from erbenson.alaska.net (246-pm32.nwc.alaska.net [209.112.158.246]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9886GCc025640 for ; Tue, 8 Oct 2002 00:06:16 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id DE5AF3A17 for ; Tue, 8 Oct 2002 00:06:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 55AB84104E2; Tue, 8 Oct 2002 00:06:15 -0800 (AKDT) Date: Tue, 8 Oct 2002 00:06:15 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008080615.GH13549@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKijDXBCEH69PxaN" Content-Disposition: inline In-Reply-To: <20021008094316.A4351@pc9391.uni-regensburg.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --gKijDXBCEH69PxaN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > On 08 Oct 2002 08:57:19 Juha K Kallio wrote: > >Sorry, I just noticed that xfs_fsr was in xfsdump, not in xfsprogs. So > >that should be it. But I ran into another problem when updating > >everything: I made a Debian package of attr with debuild, and it made a > >very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be > >missing from /usr/lib. > > > Hi, >=20 > I have the same problems here on my debian/unstable box. According to=20 > Nathan Scott the builds are fine on his box... maybe Nathan should check= =20 > again?! > But I can build proper packages on a debian woody system.... >=20 > But you can use the latest xfsprogs, xfsdump and attr binary packages fro= m=20 > debian/unstable, they contain the fixes Eric checked in last week. what does /bin/sh point to on your box? this smells like evil bashisms in the xfsprogs build system, this would not show up on boxes using BloAtedSH as /bin/sh but would on boxes using a more purly posix shell such as debian's ash. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --gKijDXBCEH69PxaN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2ikfcACgkQJKx7GixEevxP4QCdEXTVTMmvZn+oqEJ6S5BPLbvY hy0AnjnyQ2FqPpMIO6AEGjbUGC1BBUcE =6zqs -----END PGP SIGNATURE----- --gKijDXBCEH69PxaN-- From owner-linux-xfs@oss.sgi.com Tue Oct 8 01:10:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 01:10:55 -0700 (PDT) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g988AqtG002799 for ; Tue, 8 Oct 2002 01:10:53 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17ypS6-0000Xg-00 for ; Tue, 08 Oct 2002 11:10:50 +0300 Date: Tue, 8 Oct 2002 11:10:49 +0300 To: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008081049.GA2018@psychedelic.baana.suomi.net> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> <20021008080615.GH13549@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021008080615.GH13549@plato.local.lan> User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 12:06:15AM -0800, Ethan Benson wrote: > On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > > On 08 Oct 2002 08:57:19 Juha K Kallio wrote: > > >Sorry, I just noticed that xfs_fsr was in xfsdump, not in xfsprogs. So > > >that should be it. But I ran into another problem when updating > > >everything: I made a Debian package of attr with debuild, and it made a > > >very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be > > >missing from /usr/lib. > > > > > Hi, > > > > I have the same problems here on my debian/unstable box. According to > > Nathan Scott the builds are fine on his box... maybe Nathan should check > > again?! > > But I can build proper packages on a debian woody system.... > > > > But you can use the latest xfsprogs, xfsdump and attr binary packages from > > debian/unstable, they contain the fixes Eric checked in last week. > > what does /bin/sh point to on your box? this smells like evil > bashisms in the xfsprogs build system, this would not show up on boxes > using BloAtedSH as /bin/sh but would on boxes using a more purly posix > shell such as debian's ash. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ It points to bash, and the system is quite "debianish", no manual hackings done. Yes, I'm using unstable From owner-linux-xfs@oss.sgi.com Tue Oct 8 01:16:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 01:16:58 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g988GstG003334 for ; Tue, 8 Oct 2002 01:16:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 BAA02254 for ; Tue, 8 Oct 2002 01:16:53 -0700 (PDT) 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 SAA14846; Tue, 8 Oct 2002 18:15:35 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA58235; Tue, 8 Oct 2002 18:15:34 +1000 (EST) Date: Tue, 8 Oct 2002 18:15:33 +1000 From: Nathan Scott To: Christian Guggenberger Cc: Juha K Kallio , linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008181533.A254596@wobbly.melbourne.sgi.com> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021008094316.A4351@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Tue, Oct 08, 2002 at 09:43:16AM +0200 X-archive-position: 865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > Hi, > > I have the same problems here on my debian/unstable box. According to > Nathan Scott the builds are fine on his box... maybe Nathan should check > again?! > ... > But you can use the latest xfsprogs, xfsdump and attr binary packages from > debian/unstable, they contain the fixes Eric checked in last week. *cough* -- those would be the packages I built on my (debian/unstable) laptop just yesterday, right? ;-) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 8 01:22:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 01:22:06 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g988M3tG003798 for ; Tue, 8 Oct 2002 01:22:04 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g988M0I08693; Tue, 8 Oct 2002 10:22:00 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17ypcu-0001aZ-00; Tue, 08 Oct 2002 10:22:00 +0200 Date: Tue, 8 Oct 2002 10:21:59 +0200 From: Christian Guggenberger To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr broken again? Message-ID: <20021008102159.C4351@pc9391.uni-regensburg.de> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> <20021008080615.GH13549@plato.local.lan> <20021008081049.GA2018@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20021008081049.GA2018@psychedelic.baana.suomi.net>; from bunnyh@psychedelic.baana.suomi.net on Tue, Oct 08, 2002 at 10:10:49 +0200 X-Mailer: Balsa 1.2.4 Lines: 44 X-archive-position: 866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 08 Oct 2002 10:10:49 Juha K Kallio wrote: > On Tue, Oct 08, 2002 at 12:06:15AM -0800, Ethan Benson wrote: > > On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > > > On 08 Oct 2002 08:57:19 Juha K Kallio wrote: > > > >Sorry, I just noticed that xfs_fsr was in xfsdump, not in xfsprogs. > So > > > >that should be it. But I ran into another problem when updating > > > >everything: I made a Debian package of attr with debuild, and it > made a > > > >very nice symlink /usr/lib/libattr.so -> /. The real lib seems to be > > > >missing from /usr/lib. > > > > > > > Hi, > > > > > > I have the same problems here on my debian/unstable box. According to > > > > Nathan Scott the builds are fine on his box... maybe Nathan should > check > > > again?! > > > But I can build proper packages on a debian woody system.... > > > > > > But you can use the latest xfsprogs, xfsdump and attr binary packages > from > > > debian/unstable, they contain the fixes Eric checked in last week. > > > > what does /bin/sh point to on your box? this smells like evil > > bashisms in the xfsprogs build system, this would not show up on boxes > > using BloAtedSH as /bin/sh but would on boxes using a more purly posix > > shell such as debian's ash. > > > > -- > > Ethan Benson > > http://www.alaska.net/~erbenson/ > > > It points to bash, and the system is quite "debianish", no manual > hackings done. Yes, I'm using unstable > > same here on my unstable box... From owner-linux-xfs@oss.sgi.com Tue Oct 8 04:48:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 04:48:42 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98BmYtG017616 for ; Tue, 8 Oct 2002 04:48:34 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g98BlfK08540; Tue, 8 Oct 2002 13:47:41 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yspw-0003ay-00; Tue, 08 Oct 2002 13:47:40 +0200 Date: Tue, 8 Oct 2002 13:47:37 +0200 From: Christian Guggenberger To: Nathan Scott Cc: bunnyh@psychedelic.baana.suomi.net, linux-xfs@oss.sgi.com Subject: tar xfs problem ? was: Re: xfs_fsr broken again? Message-ID: <20021008134737.A8760@pc9391.uni-regensburg.de> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> <20021008181533.A254596@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_gBBFr7Ir9EOA20" Content-Transfer-Encoding: 8bit In-Reply-To: <20021008181533.A254596@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Tue, Oct 08, 2002 at 10:15:33 +0200 X-Mailer: Balsa 1.2.4 Lines: 475 X-archive-position: 867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs --=_gBBFr7Ir9EOA20 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 08 Oct 2002 10:15:33 Nathan Scott wrote: > On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > > Hi, > > > > I have the same problems here on my debian/unstable box. According to > > Nathan Scott the builds are fine on his box... maybe Nathan should > check > > again?! > > ... > > But you can use the latest xfsprogs, xfsdump and attr binary packages > from > > debian/unstable, they contain the fixes Eric checked in last week. > > *cough* -- those would be the packages I built on my (debian/unstable) > laptop just yesterday, right? ;-) > It seems to be a problem, when building those debian packages on a xfs-Partition... the Problem seems to be in tar... I get proper builds on an ext3 filesystem... This is what I get on my /usr xfs filesystem: bonnie79:/usr/local/src/attr-2.0.12/debian# tar czvf attr.tgz attr-dev attr-dev/ attr-dev/usr/ attr-dev/usr/include/ attr-dev/usr/include/attr/ attr-dev/usr/include/attr/attributes.h attr-dev/usr/include/attr/xattr.h attr-dev/usr/lib/ attr-dev/usr/lib/libattr.a attr-dev/usr/lib/libattr.la attr-dev/usr/lib/libattr.so attr-dev/usr/share/ attr-dev/usr/share/man/ attr-dev/usr/share/man/man2/ attr-dev/usr/share/man/man2/getxattr.2.gz attr-dev/usr/share/man/man2/listxattr.2.gz attr-dev/usr/share/man/man2/removexattr.2.gz attr-dev/usr/share/man/man2/setxattr.2.gz attr-dev/usr/share/man/man2/lgetxattr.2.gz attr-dev/usr/share/man/man2/fgetxattr.2.gz attr-dev/usr/share/man/man2/llistxattr.2.gz attr-dev/usr/share/man/man2/flistxattr.2.gz attr-dev/usr/share/man/man2/lremovexattr.2.gz attr-dev/usr/share/man/man2/fremovexattr.2.gz attr-dev/usr/share/man/man2/lsetxattr.2.gz attr-dev/usr/share/man/man2/fsetxattr.2.gz attr-dev/usr/share/man/man3/ attr-dev/usr/share/man/man3/attr_get.3.gz attr-dev/usr/share/man/man3/attr_multi.3.gz attr-dev/usr/share/man/man3/attr_remove.3.gz attr-dev/usr/share/man/man3/attr_set.3.gz attr-dev/usr/share/man/man3/attr_getf.3.gz attr-dev/usr/share/man/man3/attr_multif.3.gz attr-dev/usr/share/man/man3/attr_removef.3.gz attr-dev/usr/share/man/man3/attr_setf.3.gz attr-dev/usr/share/doc/ attr-dev/usr/share/doc/attr/ attr-dev/usr/share/doc/attr-dev/ attr-dev/usr/share/doc/attr-dev/copyright attr-dev/usr/share/doc/attr-dev/changelog.Debian.gz attr-dev/lib/ attr-dev/lib/libattr.so attr-dev/lib/libattr.a attr-dev/lib/libattr.la attr-dev/DEBIAN/ attr-dev/DEBIAN/control attr-dev/DEBIAN/md5sums the tar-archive is attached. tar version: bonnie79:/usr/local/src/attr-2.0.12/debian# dpkg -l tar ii tar 1.13.25-3 GNU tar Christian --=_gBBFr7Ir9EOA20 Content-Type: application/x-compressed-tar Content-Disposition: attachment; filename="attr-dev.tgz" Content-Transfer-Encoding: base64 H4sIAKrEoj0AA+xca2wc13UekrLNXcsN7ciuXDv1tWRbu8pyX1ySEhUlXlFL iilFMuSSkqrS6+HuXe5EszObeZBcO3JaqGnBEmqM/ErR5EeNNDD6gn8YgY0W iVO7jVOkqIH+iFEjSdHWreIHYBiuLCBu2HPuvfPY2eXLpugY4UDLO3Mf55x7 zrnnfPfurGTLMrpLdCEhXb8rmcwk+3t7oWRXsOT30CHZm0mm+vulZCrVk05K pPc6yuRetmnJBiGSoevWev02av+IXrJjf9s0rpcPbM3+PWD/dCrdu2v/nbga 7K9oRdUu0e32g63ZPw327+nN9O/afyeulvbHym10gq3bP9ObTu3afyeute2P f5Q526JmvPLBeCRTyWRfJrOG/VN9zfbvT/amJZLcnimuf/2K2z9xOEwOk0G9 VjeU+YpFIsUoSYNRuuFPmkwpqlLUNTJsyLWKUjRjZEQrxgnJqiqZxP4mmaQm NRZoKY508JOvKCapGfq8IVcJ3JYNSompl61F2aDHSF23SVHWiEFLiik8jCgW kbVSQjdIVS8p5TpUIClbK1GDWBVKLGpUTaKXyQI1TAUkSsdT+Ihtw2PTZJSa IAYZpho1ZJVM2HMgOBlVilQzKZKSQSasNCu0RObqbOAQSjYlJCNDOrCTLSC+ 5lQ8iUtE0RiNil4D6SqyhXNY1G0VqFNim7RsqzECXZHOmZH8qfHpPMmOnSNn spOT2bH8uWNkUbEqum0RukA5LaVaUxUgDeIYsmbVYYI4+nRucvAUDMmeGBkd yZ8joKWhkfxYbmqKDI1PkiyZyE7mRwanR7OTZGJ6cmJ8KufOYMg2gLIRA/og v2OF4FwcSWSt7jF3JqWYSIhZUSiceQrMjxRVWaliLQ4EDkaJ1MA+Olp3XjZK ijYPeiobUNIq1ZgudG5QVblA0ZFgoMqthIpeUEogDghMFS1GFisUhXf1ohuM ANYtKiaNEbmGDeAXmgr89cAky4qKLCZkC1g7XMCFFaZVEDkWZElKOtF0i9Fl BIt6dU7RmFOYfPY+h0CtuQK5bGM4Q9QHr4bOJbsIrgHaNHUwteHa5hysBLPC XKYiL4BaaZEqsJKIDHxr9Q3dG2kIDyeyqoOuUaIGGY/BZHFGoEtDsWiz1zMf cR2fL+8Y6T1K8hSUTsmEKhcp6SZTNg7v6UnGyAndtMDCp7MkmU6lUt2pnmR/ DOlMT2XduQ3qmiXDtMH6ulFlxAfWiCYxghmAZKtQB/LJFphu4sJindE8DbJZ MlhmRqGLMTKYJeRoJpnpQS0POMwqllUbSCQWFxfj5rwSB6MR1//BGGW+Bvyy +PyTqQtUBIqMEZPSARIgq5umQzYBav08LVpmAiwxAuQSU8MjwxOjY2x4bqmm yloChibCB5UyxK4yKRSy+fzkyInpfG6qcKpQCB+EWkWjoaYGHMJHFGuqbeIn TJcg7mnkwOAB8mj4INUgNIbDLGKHshrYvAqm6B6ZHDnbDcLVYGZzYDIcpKFP ewmcZCdGcFAE7Y/9vTZyAGKidYBAGDO4akAdVcU0QTfROJsL5wjBkJKqvKRU 7SoxlUcoiSgaW3OUXAApqYqOb1DLhvsSxAuwgtcW5VGCLTyX9YKs2tQJCHN2 uQxGgsgJg9kSYj0LKF4kCilDVWExj8rGPGVhAEUwweMhExnUtFX0NRyUS58Y GRZywDoqUT4JoXeCWi+czp4tzGRHp3OjubFQpC9zOJVMZ6KhxGGcIFGpNg/r CAUWIqIShBaGVHne5LERsxiP9TyC8lXPF62psOXjzRXlN9nywNxZoqZi4EQZ NREEgNacYnVjaCPjk4eg2dLnWQRsMYWT42P5ofHR0fEzoeQSoiiUXoSvsq6q +iIx61VV0S6YXJ0E/KOiyVXaRGpyfDzPiaSRCMyHINjp5n24H5moXb0WY/Rt jEVBKvnJ6SlBJoNkLArzZNDAIIvUUZZlAN5iM8MQBT6n1sMhuAiBGKiV1nBf zwmzpZKCXgpBsLyOJZgJKPpNowXWMECEeescRGyC7mZG35dJBidz2XyOqSCV RBXUbAhlRQNCGkSVsqyoGI1RIFi6UFuqw2SRXbNFchOj2UFOKu2RghkF6JR0 yoIXJ+TT00lOrQJuwGbEvNlVBbqBSTBHuutVrGRmWtQGEsGKFmswS1RchTHS k55D4KYq80Ah5qxgzD6yaTKIxNa7l5oUEATXLRA5A/meIQ6CeIOtG71chhmC XBaHfHqNW5fKRZZnDQrkqQb5SMQGFKsAub3A0CNwLV5wZfbaDrkUwcCWXuWW s+o1iuEWQBCmZ2cIxNkQhLWedMEKhWS1UMT8cwwtoNnVOZgdyAlUDUQdiicF UmwYV9UB6+KwfGJogOCTWEYRWKOoRyLPQ1qLNg3kSjifmmWj5+oWdfUiTGiS 8wuy0Y16LM3i+IvehK1jjgNMoekZqNQgh1DTElhMJ/IcQj1d80UnsAeDuvAP cQqO45ZzxFFm2azrpKYDPVh1+rpaRMWTR1lEki2Z5wK/I+Gk7YIzbbnAoiyE Xb+icepMxyJLCI/HocWKbICyCujGjqZYIwtvkbHp0VG2YUDkRkvRgI6YU7h6 GlYQfct8YrjZ4OsggjwORx2fLuoMhXC80LgoePKJcUhZQtdUIHwtxZwU1EQa mpUiCuZbkGIzwbk1hJYQCwi5sfzkuQhvjnEG0VDod8KhSCSwEA5DPTaQByJs DlDBh0XPE19n7CjoRaPdn/ZZGmnPktmoo6ARTGQI3mEmB4o2oHvjAMsomCdA btMuFgGdghqbYgXPdyOWA7NhIcL2ggFrmFqJ7wNk0/Ipgi34RdisuYGJqwYJ uV39PAB3i0E8x0B0ZnQ1yCPMyZ29jcA0Avo7Hu+L849QQ49EcXdIy7hecX5o UdiFaIjb+V7IzRyWzlCIJRvAZ0FETW5FOq9ozFcEGPCmh4Iz1pTvWcC3lRLb Q7jwS0eX4XpGdqArIRnwX3/RiUGP+teWXpO/YNPzGbFIMIdjBTi0fkGhgZXB CfgWx2nwbKXbE9+TcgFQsG6sKU+hiiMhgPvCqVwt6DUEZEwUjxRCAWogNCcR 5uzjE4XhXD5GqFWMNwZIIEENQzcYhfNsx2rMzzr4z9mfmfZcN7COwGyht6ZH vaBxGCigfBgo3LDh5USUZVE3LvBs1TSKRSLOW9ESLvsgoI0Y8iIPX03Sc2jZ TMKDnC7g9A9jKIWNEnjFB0pwkIgVJsb2BeoLeI4d0KYNAQUR8Onp0fzI+MRU KJU+4mBfJ8vVTAGn9RrLbzxJe/hiBh2XC8sTk2PcFriI2zPEEKoIis1xELK0 O/Xg6CkYzaApBKgEx1MtKCT4+JqsNINTIDKZOz0+kwv1cCmqoKcWNHwzHBaB xEs/mi9hCh2wrIWWqwKsxShi4ige5xv2SiIScGJuHLfY/gVpNQ6FnbMNCNeD HDwZ2qZ37uSnROwa29KiauPOVk1omveDVdGdwtDClg+JLCbYymA85RoicUMB Jaj1aIwksZ+I6tyaYhuqaGJxY4yNQEqEKfMUUyjg5iJGGuuchRZDhO+vZDLF GD2oWfDUyOsK3N+jx1oxLrNtJ/YprcmPNDNDETbm52Cn9Uwf44jeDwVEDi9D 0kGlyUZ9J6xgvh8rNDUJW/AGrg2/ghy9rW0Tc3M22SbuwkKTfAE3LcnrrHIR N7aq9fUVyIluyq9b6mKcZVIEFIRF+4ZzB9M9kMD0ps/h6RUeTkBHWaO6barM V93Dbgap2KGKiUeSqJA6bNirvAFxTgU2rgwTQYDT6n5O4jhxXmdrQ8eYxrM8 Ht1qHpttNBEZ0x3QaDWKj5tiwQaoywg9PZiAe2jcUPOTa4a/hJYYdBDIxMRT c6oYTeKaAH14JMatKaGqd7jNyXjghuVNB2x60nmS8bMZn0AC7PI9IkPMFV0F 29P5AQwxSN49ycHtv3ZI7P5jzklauYRCzsklv8pNCuaylKLJdyl4QCTjaaFI 4WVnrELVEs/9AQDBgLNBPWeSTXHMsinCAHNs1JIpgDPWFXUDbAK5ix3EHuBn ZgcatkWwVMpyETeoeJJLl2TsMuBQZN9MgKfJfqDRUkrszHpqbiZxDjRarnQ2 7dYLvVEtWM8xkm+ps1ODjZIZI9Gw7N8v5VZHxxfd82JeIuwJnjnjxNf+/ncJ /37Qr37Ztf73v8ne3t5U4PvfvmRP/+73vztx7X7/u/v97+73v7vf/+5+/3ud vv89y6CJ76vfhjroyHMu+VQZpg4Y0IxXPu2vZmAY6xySubFxHB4+SAQ9UYHl yWweNMSvBKJjBMsVH6JC0RxcIIaf9X15RUhyKeWNRwgutmib/PrqrP/7KyCW 3phYi++wwoXCidzwyFjhZG5wdCrsh05AhQGTzWzCnA0YF4G3LehKyT0FiLHD mQJiKbxpxFVwkz81OX6mAbmpHzL/ssdf9IUgV8Kodn1YO7xN0Xv+fUw/FFqP c/M8HV7qTjIrz29NsZvm0zQrcPL1ZiWeXNwf2qy2rhfhso9wUDWbpun3YX7g sSXLrrEYt41SuYFSYJZkfTIQrHJjJ51Q5d9tuWEeg9qHDfTXuBr2f6oydz1+ A7KV97/TeJ9K9/Wld9//3omryf7wYRt/eft4bPD+dyrT3xewfybT37O7/9+J 695PyUYR0GWCNF6pZA8s2r70kSOACVmN/y8h6aNHxN3DGNr2SVKbtv7nlvBW Ps4pneR+8SM5Xze4N6KKx27/vWhgR2m+27LkoCfJxXGSi6ikebfRvSt7dU4S lLxEK3mpUfIlEMmfl6RyQ4tYXHpifS3zBYNaTqUdLX8pNzrU1tbmWq5N6pDa fJZcuoGXGfY3Iu2VQg2Wnl5+9dIbe8/MTK3Mdq7Ye5fffUp679lVuN7+m+UX 333p1PFV6PTYnVfeg6rvS3fAwzPY+nr/5acfwPErua4n262bL71wbbV3Dzy/ HmK32DTFBl16oQtqZvhD6rnL9Mr5hwo/eB74/t4bd4OkyPpi14q9b2V2/6UX 3ptatfde/vJbv1hdnbjyMB/+5ee+2Hv1+Tbr9tW+M6JpJdc5wQi+/vEWlTBg z/KNwOvPX4Z6xu5xxu8+4AcT3Qd8Vu39Pk5Xf+Fwunu1Z9XuEvWrdqdHsCP1 3Mo3kOAPnr+8IDXIP7s/dRUmcfX5Lqtj6PXw1eeJdcN32kEFgQl9xWVzFCZk 33XphXdmVnL7JpqndeeaTb5JNciQ4zI8yUQIPemTYAIl+AZSmbpyiyvBrchh 1d53ZsqZpY/y8lVGmwBtIG13rsx2Babywv85hLpxKmC6a6Jphs/gjsvflhj/ xnqHicuD2YQZpMsnJ3XJ7wUKroiOAdhYx2/3rthd30WnFE76Gvy92dx3taPN Ymq8PNg1sWruXTU7Pf2mr3a0W/uZCsyuYOPtVzs6rNtAphl/9fL3l6853vvL xP/ivu/4mOMKXb526d/bjl6zB0QdXqmrqVeO2V0XHwCyZy7vOb8yvffynr/n bvWU4xRW+/I/Dh6b7frivy2/5bDivr4hr+MteEVhbAt231uPHY6/ET6dbjxD pBBPpiRMytSIS0tlE7NuXJKGBwcHSGR4bDpK0vGjvfEMO6NO4RF15CSdU2SN 1AxqUJXKJo1KUtysVy15DkrL4GXFuYNOcQugP7/D9xOl+JxpSnFNtyhU6ryq qFfxxHILmfQeMYcbxfOD8Hl8j9feJcq74OOPzL8L+e4lKMNi/B6hk6h47hD9 Xtrj6UoS/fC6P0Bv4mbOKyzGOvQSonToveyTzU8P88dNvnrst8/37OScAXHf Lp7fgH4fa9HvhO8er59Dv2SLfrf6ZMPrk5DPfqtFPz9PvM6CsF1QAdOWbhHz wPmHAvQqUHGHTxC/TGtdHQ0U8Pkmd9weiefgm8W983y7aF9icrZJ90L5DMj3 mHjuhvJIh/eMevT8pFGqjqbnGwLPNwaeO6Ws7xn1MBl4Phd4fljIqsPnNuCn BNrNwPMX4XMFPqdF/z8ItD+O8wOxf1+0/0mg/YnA81/B5++g/2+L/t8OtD8H n/2gvznR/sNA+8uB51dRxnbun9j/7UA7wpxnQP+KaA8D7/tA/6p4ZsGHbfIZ 5ud3ck0pFHVtgRoO/FS0eZX678vSKGWBpVBgZ7YFVS+yw2YJQk+xVmeF7AFa H8x0bzywW26sQ9jbArx6SLjcWCcw8ZqotAEsl5tampEzIkrwV1hgo1AiDD0j ylms/zVJ+jyWEAD+FstbeUxrvw12GNCnHQLIV7GERPLXWP46xBiwUfudkpTH EoKiiuXdkvQXWP6mJP1zO+f3NpZguI+BzdphcT2A5W+A/3XwdgPLj0vSV7Dc L0nfwvITkvRPov0nouzbw8vPihKvtnaxbqE06yZ/aVmA842weao3fWSz2PyI CFgONg9DHGG5thMxNALUfRwVAfyp/AcuMMyxDPe17vOfm+jzX8193mno8KrX wcn9TX3+exN9/qdFH6/1itf6eLDtZ+u0vdbUxrAja3t9nbY31ml702triTuu D9BoAhlbBhdBbIF+9CWfgznpI4gtvnYDj++dUiO2uF9qxBZPB5KhQ++TUiNm WKsf5nM/ZsB+rTBDn9SY4V5s2xwWuAYNn2nRL4gFXoRBD7ZxHdwkrY0FOm/g eSpIL3hhvafnjXJzECvsCTw3527HB++TeO651deOct8p2pz2g1Ce8j0jlsC8 da94Rv0+7nt+EMqnfc+flXi+vEs856F8x/dcQL5t3jPG9JjveQH5+54vQVny PTsp0E1GIqh+WOctkEak9k6OQbEsi/IPRfmXovwXUb4pylAbL+8XZVaUs6Ks i/Kjf615/qtu3wHwBu9/pdL9wfe/Mn2Z3fe/duQ6SDyDk24i46Ol6yqWhmzU 2Vs04YPi1ROLvzylWlVZ0SDXwQh8PcUZk4pn4mmZRFLxo+l0PB0Hu2P+TCeS fYl0H0n2D6R7B1KZaPggUJxgOZScHCdj43lSgpTKXlDBN8aA5b3QY4T94Mp9 qZ69S4q/aHbevRcixsPQF99x5T/h8f0YrKTqNapFeqLxcEnF1uOHnNmaejx1 CAeOsd/COu/2uCTFDUP/ZuOweDKeIv4K38OhBlmct4ot2AcUCR60Kws0HtbV UkHQ9yjLbOgoq8Z3mryXmvFXbCUKEymZ7JceMBn2RLViHemAeGzsjHg1zv+e C1cZ5xAu2oYBsON4KizP0+PJsEEXFBwBFahtk7PDV2TF+x2KBqKrKhhdiPuZ sFt1vE5NHDYExmKv1nJlJ0oqACS8C/MKFM6tE5KeVAz2+7G6b5aOv2mUlkzx +rjHX9EG0CQlxTh+CEPUoV/W71M/atea8d/Ut40HRPgt/v9/mf7epETS1/M/ pXSuX/H432B/syIb2/6//231/3/rxf//L92z+/+/7cjVwv5VWdteH9ia/TO4 /pPJnl3778S1hv3hs33Rd+vv/2T60n279t+Jaz37O5txQPLzj3wAHhvs/9K9 GPMb8n9/OpXa3f/txHXPSmfno889cby9w7O29A8zP9Vf6et67EeFL7z10Ne/ 97k/bX/0Z3/0xEOvfevG9KGnvv5nHXv3Pm199dnPffPByT/+8XcfW/zmfa8s /7zv4bdWfnjP4k8vvvvjT/zr/0ZGfnTwa28ef6395q6fnH9WOT5Q+3/23jqu riTtGiUkwd2dg7u7BneH4O7uEDS4BHd3hwR3CO7u7u7uwW6SnvlG7jvd8073 pO/9fVl/wTn77Kq9165aT9VTtRfoTrm/OulWBkoDMgSGbOYG5tr07TVEXkMZ KdbiHMqV0KZaFeKtN+YChKvnO6uVZShhhkJ9S0Zs5CHFbZht9nQef+j6uQxs GJK9fYrFIcWVvI9TCMttxjws2KOh2pfoF9Z+3JWIBfZc9xDBeyeVOXwtO57E GWHpBs/gB2ZlIiA2AQDGVQoYbRKF4DbN6531NbpkI1HVIAzLaIV40S+YD4QO JfPAay/Lr7pxMez3rjfuYJJdETn9qWZGr7GEhvtObuMDXgwn1NngnBeXmd06 C6jfU4UQn+qqBGOYsGGo3N/6pEYKzsJE3KkavUfiXt2fsSvdf7ZxJfSgZEon z2337rzWYqc0GBwn1z++oGzUGMZVuggQtBXdbpfz3xnYPXlkz3+jsYyJR3XE YWRLxrnkEicQOun/Ihy9PpkHj2p7OSJoN5xjUmzfYxfS/X0s8UcqnFneybho JDynl++DM0KLCzOkPDnlJc079rIHCOsIVW4sc2FqG+exBpDkNQFxcaufT2nf v4tFaoc85yYSOxDCA587HD0m5PYho9ldpLthm8Jzl8EzhxOb2PdOed1Ip9US 0XV5Flm9REK3N9AjCMVls+nLq0lKqpJxXRFTVcd2+tqQC37zgGjIPCOKY9It iCnRPhN0mf/WS0umgIJ95Q5LHXtMpMdgWTW0C64N4LEcmlHgbG3J1+kjRgJ+ nJiQdqPOqq/kLd9ENzniiciduYlHFBZ+6hGxnEnOy853NKYqb6OP2N+A650B 2x9/6VsiMNCOthr7xvsGIXVsHw4qCcShah7NUcWaMnK9pDOqnBUBvqZXoU4o qh4iTCrDtjUUgU0Ys5+gyg/M2qVQCaaPkL8zTH+tbX3v6SkpZFoONDsM5oB8 m2pSbYbwDuL5HbSreSBc/c714cuP1axlxNjgQxBdRDtP24Dotf4DciJ0cY3e VEonc7/1D5Z6K6tImoe3L9ybLcgC3Lotc2o5ezlTDcS7iTEh/BXrem9DzGjD g8LEOG0VWNI8a4kMWCrQVBXOsYv3Dj7hLXodziJjOW7EPXUrCE5VT0eB6AYE 88GWo6LiJ9i759iNNpC+ttecFpA+xEnFjrTfXUcOWhrzSBS3FWqQa1fsja8V Ql7TJTx5PdO3pRrOSbvFq0RkFMcpU2GQS0AKMcXJP4UfCqpBh1+YGy9g1xlL K2Oat4jLCoIN3yVpmYB2t1cQtMt6xOZlJ1pAs3ySZf4Jj4vWtA0K03rS6y1G XqdtjYsq9Wr43uMEpfOogIBUhe6KgkwYzxgmb+1aou24tItRyFOMstRoeBoi WTKNn0Jxrn5xqdUwlFwBJVIRv0VdDJYLHDSeFSVDCUzktPOho+wrYVC/TLlV HB/XvQffSYywMQcYkBrvd7y+o3XJt1QH7hHDFCMCX8zPWkfK5Gt9oiSdl284 0rbAG43Oy3dVt2gaVaRQ31W2QWriTOIxzzCHlnMzlqMi4gkM7hQIBkJXN+H6 VfWn4YQDb5UIu5BLLE+jJRmhJ3LgfiSBXWfNi2VIwUoCPoSqUxFkkkxX1MKN U7Hds0nJGWBzA4pU7OmS5iwgE0nGUGvroYVjqzi0hFlp1ldg5FDI07Ge/CCw hJmpMnFcepN7r58irkEkT/8Kd2JTFk+aPIBTheldZtCs0TyWvED+rOIzWmZ0 FiBnMlgdCpA8pO2SznV5kRdi5Zn8UTRnc0rsjQixUQx0fiOLVkuWSCpNHOX0 pQibClSs9fWXW1SH4SL+Yqg/u+v/jl/T//8z2/47A4Df0n8WOuZ/1v+vgeBP /f8R+Jv+/x3bQNWKGl8DACT3mdK6U81D3rfJUL8EADUgcj1lKXgvgZGqBObU ieQAhYzHpSv1OQ+Rs87otGi0hGfv01yPmwaPQUUd32T0Zcc3xBCBnxSrOmiy 26rtGPD7FZgJh46mFhQim+0pExhDlwoxTufGto8ZLYg2IXQJzcdw98Ue+S6N byWzoLqOqU8V0WJkZS0VtI8poJJtVfglx1a5rhGqvc88MGn+jEkTD9mQ08b9 +Yz78wto7n783VW6N0HIX+5Qk0JbpKJU2Z57yXIVcLmU7o0aPAQf+M5fAY1n ranrUDy7OjKM5DtHvc3K/Eg48TbqUbSFVGNSg2wPO8PlqLbYfm77cQKR+Ya9 DkK4pOssBmS4MP08OZ8fwA/wYQ0KLbu5PAASuYeGHid9f7JxYo3ljZMzuYDu C4rxeDb48Gz+DNabOU6pWKgaBxjxKFcvBDul93yyidKiyrvYujSMS8nOLysX sMIVWOrLQe5fz7bLk2nnvwzg8xbDDDPs1amPETMwWAt9+7BeI1l8+Y5TVCuk Qr8+ckGbybqNbFVwOWKlNbwcetZj8xEU7DP4OGi8qDU4xPEiOXbVvRBGkYTh w4teyl7nNRMnNjGxtdefwwtpJdXE4UY4Re4zNmHpp9A12cH2gSV9QDNNiArp U6nXKGdDu26xUSrvUurraGR1iSR6QZXBeCU6ZG2nRQmfwVNShlS5RIbmBzNy pOlWMcehWLvxKVAn4tMY0IctS0u1nE0wc+fWSb+I9Bl7Kq8BRDAf5igTXz/T AHkWCTyoeLlq7jFVTyONs5FDE1ad9QlxtlrDczPrDogkCjlL5VXkgfdjGeGW T5rpg4U/PJLBuX6KgOc5/BS39WLlZSurYu6kJh4xDD3S5ii+CT5uvTWHJlK7 qCNpQhCFz5qIRC9SnyicGSpu8C5O2CYW1k5Rp7+IM8lBkO5k5qVBElCSe98p EAp5+IWYKohjuuKVriqJCrqGld6RamH20rQ2FgDHs2ye3u1RXcR/HUiH1bs4 w18R7bX0aOX0J352oKJiwTbStl58mGK0dTQ7/lIzZ3/AIU0M9LZn8XpNltEh /7PKbs98Je0VQfJb4Hmqe4sXIS6bVGv8ki44bDwmgkMvux47ColdYydsM0Rj qad8yJ19/MdG8zNEmYsDukqAH+j6aGGi08eTNFxradHKAjt6+94TbTDho/dN fo0ou0wwVFIOZy/kPPLdMa/C2FEpiFOVoNdhmR2vO6n7C4CNsZffZq4ibZX6 aYgrLic0cOZaogh92bR8cHjP1Yd+uXGHOOc+qd4aoXNA+068NeydmRenQHp8 5EwQ6Sneh9ddn96g68ZBTvMNgw6/xgQVZGnf4nHfMY91bdQ6C+b85Kyty1Bj Z+PxnJdu3TjzOEekuf5FVeKawjzNbR5WEJUrAyae7PnZ/1Cs4T7mZFQ/iFm9 +U6Suyn7bKqany1ipN5fulD2IHTlrdZhphtbKPf5NOvVrSTSVS0rKiwbtpSY yoeS6x05PnDU6K0jXSGP0FIrkr5QEHDvTKQHbUScAS971BK7nqtNEFLfHTZs xXZ4US2A0ZuktSyEouNPEmN+qNKiWeJS2Bt8mMcOmoxZXTjGVLVaTaEWzMWO 99RVcYVpn1rSpj5/DMGbOf3CnVceC2OcQxIGYFAJMUoncSU5zxWHACk5mJ+e TfOQRiVGyYC2TSDSfXsRyL1j5lg5aLUzhj5CiRMVV6sxRmfjVIju6tLI2tDZ syB2BOXja9AxHJivaj58dnQ+AL1re8wHiyKxh/3B3P321uuEQmTcsLtkz709 ZHvwfGSi9RCBoYLZQrs6PmsOvc1wH0eLS/HYx4baziy2Da5pJMqZyhmP3TNw /FxB/aW7/xCdQISuWiMHOqHgBxE6zPu9KGlixuZhK2Ags72PTsgNaLnwUdE0 jU3R3F6US3s3N/MDPk+VNIrMdUXY7lC+brag96h4jmGI2tD/Sf//a/r/d5n0 3xUB/Jb+0zL9v8b/LN/8n37q/38ff9P/f2AbqPitpNUCK1zThRLUYnCTzCRx q6ZjcMbypAVUTo0OmyDkJp84QXIjElmEgu5J6Qp6v2LM7J6JFQIbrtXyZ/Q8 2JeR3FDaFZDGEJQ8/quTDeC7bSfurRC2hdUBYklCpgVbIFyuAqVrQ2Ddedak XG4O0EnVg7W7CLfeZjMitQEfYXGpOSYkTGLV+PMqlosWOyY3wfWV5ZOYGoaV cz6qKUs1D7VIvw9R+kik3pbxkvUYCEb7FP1iVzBdBZZKsNdSh/mJGR6G4j6Q g5rixeN66eFjW8frqhYA9Co4Jp32tR2zlv6ERE7up1WhnDykPa1TqUR1ltft wrqH7rMzuxNHVwOYMJfchkFKzXkHZFAx4KPCdIQubp5uFEsvH5gBDR0oIOCf 2Zkr+NAe77D4n3F5NU/pNqNfxIjp8are+rkWqnIrRmaPRB8asml8yrtIZCUh 3wsc2KtweN7AQw2XYxFBi80WP7Eo0QfEkwhmxJanuPWSugH72SaAHiA937rn xt4FNNNuZit8qqnb2bW4+IxfBUfpS+VdXoJ/dC3DGflQM/aFLTeQTJS7p6pf 4KQDDeptEBkunI74KS8ImmaoAJ5PzqFeVn4RE8irrFEucjdgtTT4KCMcuyhO 94jxabBcCwnePt3FuPsVMt0G5TJfFy424zlhhfxIXmRjb3Jk7JIbAdtNZRGI pyQlmDLZcOPZoC08mGqhLL0mbM/mKt/zAEpGw0HLzsV4SXzrninsvoFcYWI+ 25bpuG3cOjNwB6APj7XkZwGqkAi5xVnojV4QOA6JMsL8AfHcBahBoIUCPZIn ZfEtre9BGphcnpkJWb30zRipfOfH60aRZcflPBIw6WIOUTGMYDQyc8ZCqxh0 p82o7AxJYQRTJlEebxdRTPP9M+BSg7ZAKu8bG4M9S+SIa2aic+c6TXaRrJX5 Druem7dDmMpzHT9f8x0KEN1QCoXnaBY6Tz+sqMfsqkv1RF9+lMjEedsmzZ+S xEjttaXv0JLSdnO29CgwCH1LTOKBMeUxNhfXHxcVYyVeaL9Bi0cb/ygepGUN v5tSvsgd/kJfg0ONQyjzhurtREWqLfD8TlHZq0Q/b44tfluEDy5MiUN37nvt q3d+yNm3eSXFkOWhpYZELw6ysCOJZyZva6OKK+4Fk827yO2GozQhk1mQhe5i kHb0Oy7T1hz1TKwSQZKIpEAWm+Ouzx73HZsHO+tJVHIGyNxeJVqmwb45G87C 1zBdAinZKFrtryiVvz0j8vHuzLAYWgVkfArjNUZKXuoquUz/dFO4UhAD3OZA joLhvMx1PkxHWGDIv6Q/zykvoIh1UBffJ4fiO+nqQrsA6kjvdabBHP7KnDbm iP0zFhEVEQlJj6yYpsy0Cm5axUbf9qZANL2LsKw1Tc2pB2L6LAkA/Lc7k5/4 /x1+Tf/tftD8P/PXwf4/5v9Y6OmYfur/j8A3/Xf7rv9/YxtoSHEhbIEZzn3n q/ijNsrEQI7GM4OtH5J/8Dqar67qQlEGZORGDikSv406n7/7MiyD6tqkeVnI s4aaiDG8NcjGEIQrhP8ejbfipgCSksfFaqrobLcVO6WHarOiCMs811L/dbV6 9vcEgCmwvIZyDEzzLMiV2DZmFbxbd6xFDldrI4vVMkxeYZGCJWNiv0u2LShD qnCErqSOojGoHryRFp5kxb1JHNUadoj/YR6/IwGahh5OyaieSxS5hnRL+9Hl jADrpSs1qff+rfJ1+OkpxC56DoibIveh/pS2deyTDYdWTqVCZ+5ie2ygA9m6 9KnPuPMUEtgJeMHMk0x2MAtuWrPOu1L+stP+qUsXEIJcLiiVEHCEHbwVkXug N2Fgui1esq+MelQtI8PUQGHTPFL7hgvwE3xj7orkV86SA2SdVl/CsHpXRJmB RmuFiSo8B1OGYaO/Iy5q90a7xe2hebswTll1xy5aGlcpyJy8EiRuGxG3S6tW Q/bwEDGRHkZYrRC3zGFkS8S15KLwKm3c3wzNjo7am09lsKk86Lmuo0buC40L X7q0bqTFaesLVXx2QWQvllUWsPlZKvATwkjh8WFiZVz+ILio3ZWAt+yLx4yc inTdbjytVG3OezoPlvgQe0SC6Qi+Cw18uk1zmUtf9UVeE85P75PdOAVXhKki WK6JPW+b90qN35vIHqdybbxLdwO8Bma3cPS7nQdqMGnkgqZvUQKMm9cL1Kj2 FIJBmGnTgKTihLKsj+w8OOSwo+dm2zyolwmdNXjrMsgl3ZwCWPS4vngxB/RZ a+1cJvCH4JjgiwwAruV6+95ZUcuz/tHPLy3tBST5TWfFiTiEwCQOfGg8z2E+ 0mdd32cSumR0k8GiiFcNRuCtnOe6jUwwNbB/TgFJydExnbSYnY+w7Y0qsuIY 35MPMTlWuwyd0qgkVawT2kyyZtgX2w4RhpNCI7PonggmYCENjgKcIl3AW55Y Wmo6V6nl8s9gq+xfjU7whFhOn1M9nZiGKSPymY68XAZdrD2H+xIiYKVSjraU rh6DVsI5QwOvvsd3pNAWTNNrGshpfXt+DMa0mez/pZfZMffzlsVuX1wqOoWi AkJqGfCcoTZAoWDm/UT7pCAkYnBeSK4+eKima6iZa3v1fpwajIm0q2ZxanMB pqJLEkk52MLlwhR9omEfXDhiMSYfaT7RMd2+vzgZ8pHb1BftEAibTzA3/ZEp BoJKQfwnTomUlnlKqJxqh8qj+bZkIsadZL5+eLAST9QSmEwo6WAMlAbyY68m 8vwMEZo6d4UFEW2mlIR9ipAwEj8qFJYfHbRWd0QQu5oqiSg9Oa/ZzKIMEDaq LbefTCQ3Cgwy1RGTIIzxPIdN075w0eh8iBMnosTX3VyYiO9M9+YImTYlYH/s a6jJq5Ho2h9F0FFsj74uNxhJCExVH6zqoXZB8VaOJrypZAwOL7kHeUo+yWTA 6zVYqbVzZNtcDoogiXaUVClSx/N48bpQNevTOKFZ864xbzMjEY0QX1czm3ZD HQSXZIlHY7LR4ucWTP51Pg2M5I04Am6xGUmT8eEIbE3N60yhmcnqcu6Q2sop hKxybGjE+iyvWwQkFZdatMtBEH/Ddzrn/nb4IzErF1Nu52dLJV/60Q1BLJBg QEKMBzr3NK4dmiW6cmFt4GmMTnH0P3PjvN80kBacn51lcoNzD5igYah7Ton6 7KicyA60LWvpSlIVl/T40X2PG2NHt1aRjs0btlxZoVdtBK/UWNKnRqUyCYy5 By4S+X7/jXGvHEpMod2sKJkkQsJyzgVQK4b73Hvhz6kCj+fsHHtKEpevKgpa VtzFrkmQyy8PA1mFcdlJAnj9pZu1n16k81Ehof9HY/Y/Er86//8HLQD436z/ +2X9BwsTLQsQgN7oj7vOf4n/y/X/1/g3/DP5p/vJ/4/Ar7b/PygB+B/wz0L3 bf2v+R94of8KP/n/1+3/T+T/W/73J///ffxq+/+DEgD/a/7paekZv7V/2z/0 Uv9n/OT/X7f/P5F/Bvqf/P8I/Gr7/4MmAP+T+O/b+//p7X773L8bP/n/1+3/ z+Sf7if/PwL/mn+GP3f/B8vP/R8/Ar/G/1/fRkTN8F/e/8HM/M/5Hzrmn+9/ /SH4W/7nb2wDHSnpfNv/8TisZXNKS4mtXi1KBzXr/0LssAoYa6Bsqph/AuWX 9Z+IhazLZc/NHHJxRPlHnjpL+VvBekGfXW+WlxCxCWkAElFbjTsTr9LajF2s /PoFQDKrq9VZFBPgQ4jx/YLzpUfOVpRmKOrGDbqK1Qf45rl8g407vacgEwJY 5LvPFhtDy/RYH+I7jvRapcvUXrz7bPxqF4uVUWjSMlp8Y8ZWBaySRTEmY6Yl aLKhVansiwEOjeJY0Os8Xa9+FWtwLZFYFEniVVCI85xgfe+j8PcrRCE5Fdhw rOLV9CjjVKVrBwsPwMGzy9sj3dYVUqBINH6uzLY22qcss3titmpk6MUNsXwF kphp0zZsNLfdq+3ZJ3TbumdAWjBGAalzb7yvrFaDKITv9BsaVIWCCYN2KOcg xBw9++r6v6zYxbGQVyO08b094PgQZT17xqUMXc3ztjOVFV4L2w82AhJFoAxA t1whRkDOL8wWwc2DzF9yAOsAypzY7ylFoGelQmUr21gZE+rITyyhOtA/7qxn T17ftb0sCnW48Zqyf+kaBs6PQ2aos4lxOsT1VLpDJDhd8IWZl8tbhPhyoIBV uN5UvQNiYXsvIwbvNJSQmeQ8JFJ/RoFQhbd66bvd66D2I4dxaqP9eKJsxFUu GUFz+3m9BUaU8e/V+k4M5mK0N0/Sri1n3ciqAjL1C2n9beWx5Syw7kzIyTHL lCN9JYu7A4K+tGqsqYWdl/jJyOxLbHcCgfCwcoyYmWJq2qOR9pPBpPPqY7OV EIRX5YiItZSoo/otw8tV0sw00JbFOZKEejo538cOhIeYCz5iQyKYl0xBNz6O 1y/ShyEyT3zhcpjkMcZNQiuu7sYZqUhSpkOW7kKLEbJpwN5U78B+wUGhT1Zc ip3e4QKbVyjwODuXotj1NEaWIMopXbIxR/mUKFklvgZp9jGKLAPjRDauGIAc Qn1cYChVZ8KI5vhSyYeYVSLrAE6YRIpnOLn9CoXvXtt/VVtYA4vEfNjgBb3w aYF66P406GtXCGv1KgcCrCnrJwu11YM9zjz8FVYo4bYlRqtNbEVfz4LtCees UzkD+lyia+1NH5zg0nzU+DG79KwLFPYTRKzKhnkmpFnZ9nKABUvuKKaEKhLm 5AB08mNnDo6F6cDQyrsW036ma6h2tZMz6K2Nk8XWksJnDzP9pbQqgUpsxc6j VhrXV4Mbe5xnUHDVKgcuqk62qe7Q0pR5A5gePNpLs1SsTSWZNi8FEKdTqeol m7Bc8gsCLrKLo47mw/2NY7mun8m29RF0jHxZJw38lvzcatpSN5R2N86bD2B7 I5KRTOZgO3yVlCamMGsQPgulJBTFdMucbLRJkMp5g2xGi/rDZ99Jr4VYF/dN yioRhOmdaHyAfqzrCmQgRo4sLXSwLrdQeeP3iDSzNoC+P9V80u0OiQG7jKq3 DV204m4xsZbcNio+fYU6nJmMhHYrq1TEcoPnr4JFU9C/cVDNI2xOTnkFw9V9 lSl0N/WUKX1p0HmgidBT6bQcliH8oZDDB+GmEC7RRtjb4JVHq+StKTwxjeEE 24MoUY2Vc8A6KRK9svEUTBYGTn7V8e3Lmf4ziFGWkumo5ruVKG5d0f0Lp3Ej 9OwOzhT1S9YMhZO9Hf8bCI/c+9NOv+erDA3/aLP4uySed937o66nCQqGTeKm q9Qr2aJI3Ok9HwkbVENnxbEgLsdj1nck17pz4C7jcO/BNCPzO9fPiJEnHgOO BXwka8NH7hdaNbYI4ByKGfliNCl8HY3fnZw7LPGqSebDDSvSPT4ps6OsHT6M 1d1fl3QO+PtWGj1Wq8ZgrMBbjj27GOPKMKtDz2p5lxSOBcL82X3+3+M39f/7 +/9+XwTwG/rPyPBN8/9R/5kYfq7/+CH4J/3/C9tAS8oWVhu90E8lWryb1saO a6T3toJjjVmeLLKO0KxxOhwzVNMLPHFCZ4zjIZZCQRsojydEbC4OKZKuRwFZ 9zrRIf5Y52v8MGxP+4ghSh+7jq6G7Jm8bqwROOP4iPC9bFQw6gvFdKRXN+U6 T4+HkmtvD3Y+Eqnvfg4Uq49MpLyhTZOW4vS4AzfcOGgNljlmLq2QC8u45/K7 Qt+MjBKMFcwF0qSkfxGL7H9TX8lDEQiITSxzVQvCutwuxae2AX3/4TWu3YuB NyPtd7YVlw93ixcWa3fkVw+wp6kKNopEwE88GCMc1U/X4ZYroKyRRYfoIPnl ijW+TpjoTk1SK5l6Cw5fmq0+U1uKP+UFS8xHtaSVUbPeCjfYaH2i2KqZgjRB WVJRd7qa+FB59wGbLIXZNVrL/aHF8b0ybUh827kuXWIp8dqgmsVrssPhS/xY KCU5mmKFkGlSSL8xWASdMG3Uo8zJDEgd0k9oTcwVjxl5cM4jIFPCIpwewHYC yxSMSeaiRq+QIGRkqQFT22hUcESxQH15H4wEyKHE49TaXPHgmZkrSEXnVbHF q+i8UgWqpZKl0yqBA4pJqIp8e9EuIYs1899AbZRJ7WiLy3cZGEQoasJ1qcEl 9r4GpkLGCZVis3l3C7IU3irmMBOQAwLVRpiByWljFFd+JZfZw2YFRPC+MIe3 cawS7W22zts9GAzTzBM1+BUG1ZogPR14l5cmhAxVcQ/oYnebt69tuigE41Rm 97GJ9prPwKDp2+uJXADlHs0Etso8UK/94z07FchVQoBLNHlg9/WvWNXZBy5h ZL3VNzFDNsIlgroQlhs3pcRv2y4GwN6Xri5xbNlcb9Y2BDrgv/e+mClbEAsR PMBq82pBDLM29fMMbUXUbDu4EFJEy4YOfo8nQGB3g9xWY/zJB6Je++NQIvUq UmrbklhlHQVygWcKgUtFGHXNoDKne/5QE8FC5ih/zFup/WCFnaO1VIhloHzi +TbDcPRJFg7E/ZJF7ljHA/2G6GNC1nsVTw+fiVDKEcdxCDDUqudGgRw5vEf2 QLCT2tuWTrRXWHux2TzBbNuVvQjGAh/YkUQIzkXIIQg93kHx0TIjncgltIMN 8m6bhRTEjXEpQRebvr8ubH3/ufdVc0v73VGPtiB11lN/AXswArpdP2JFSzk2 bejgeJ+ybFqPkMxrV/J3xzlBIknNu/h1MB4wix/q37MS3yFESLRi9KR2TuY/ fFBv4FXQfksKFUu5GgrNgu6mslNBYMzv3G9/YKpqVVk8sJPqBrfP452FOIbB 5/nitJ9/rCEj83letb4NPw4jtdKvnLmuenS3suFC/QPHAeuiOiraDuVFE0UV L6cQmyY0ASvrNk89BXZTne7SabMJC/mkIqveB0VM2QsgAtmP5laVHLIuoDXQ HeM5DtjoDQiepUSHCreaSUsS+Z4eW3I2n8pz4DXgtb60tWEivQw/yrrKRHT8 SMGZ0cgZrtJ+iDkFSd2ztMVpIr9wkItxLe+GqPz5EosE2/1gE98uavgzPEnW VP3HJSEjhw+Abk6i2UBvxdWuYIn+awlGCQhOBFg6hLmoQD5abNJ8WNg3ctyj a8jEN+dJWZVPzajneqScmHCRqLMBlkWMyNVzKVK9wBISlQwVnWZ9G3IPCPjv T1Yxjq4VPpnlCrQfqpRNGsSsDT3VKiJrasxDHZGmX2VZ2LtZpVSQLGiq0e6L wgwWiPs6MHYEX7b6T0c6yJ98wbna9UZ9TIPLelXkmke8h6IjQtajcNr0QT5k KhAzyEIftBrcg1ObJHYRnGP9nHc8pIgqS7kqsgyffjaNkKk6TEZ2o2jN7AP3 CqVPF8skZ0fKFsPgHn1eeB62gjqRIxMTBqJGF2fdHJkeodAwme3UNZqtu2cj iima77OG/b2mBqX3GTmgpW7o8B5zMH8jOMNmzmXTLkaFyx4rbPQEaQg4t7xd ZB+WgMjeoPLxI0pUfj5D0WTsh3EvOsr8w1cTd7vQwYSw3iPRWxCbY4PCjeWv Rcru3DuJZ7jLN1pnngcjVETY0ysJx5TFwZO9RM0jEaKA5xovHBtK5hSe9iaJ RYQvy3GYVbDNTdBW5zNcRPZtM0oIW6Y98aq4Xqo3MwVgyuqL9OxIvUk6K4G9 r41KOyRkvC0h1HPur5d30iN+rp2qMKNMUWNlUOCsZn8H0+2xHxy4Jskx5ghq YRd2Vnvvls2Azk881XSEzIaxuPBSnaqNDS/LUfrc93gSixTNoXsqVRaUlcAd fVhRac0e4+lDHKm38NXtEKL4CC6I77yeGBsOM9TmPBY6u5MmXext5C6IlUdP iJrH82t55oTi5goGarTjDzoRqtjCoro4lCWpnq1hno3E70+yoGnrL1VVUi71 et41yUta1rNAlYrmbZDnyGtTUHIbXeoYt1Gqa0ihaDXRgdD2SKWua7DoPdR5 TyiT42JSwROOr+LNdkJNhdBQe28pWfWZZxWyx8+W6uVGT56TfdCWkT52P4jI 7O473DmLOWyXRUron6QpJLFZFrxeBSbyvqybUnJhak7U9d3PJ5SAn3CtKrin woqn4tKwcW9PmJlQjUITU4rncono6GDI02ElaWysLZQ4uC/igcS1v26dy1oi 6EdUvH7J0AyjqMMKbYSLzT+/1zSEe4YGGamsdIaCeMuhHv5mpOej9IQ2yDPg ZJ+EvibLB0cvysRBiYAdKV9P5UEkLMeHsHDveWED3hWPksB6NL/vC03TOzas WXu38HeGQ8w3wO84vdc8mExxu+OVPl0HUZpehEnaxa2F4kUv+2SOWOWQxEef 9ajUqUtSx5EsS/LyJ7sqi38MoRt5pXU35HuRExiWYsli9TlzldGn8MRPEhzX XDW96cjK5wvKxg3JCBO2vu3F5GrQy2rUZpaJXOMdmOUzAGIS3Pzyq3qvsqzp jXAXwC6XHWb9DlTKURlOdSnsQ8l6yejx0mSi4IaWwEWjIiu2DvQYcfkjWQvL CxxN+lxklX1SOqQMrCIf9t1Sc+xkA7hWpwaoPSq3NRx1qZVmjGqPsRzY/JN7 iit5aJoG1OMvPg5q7ifpCC1G9wjof3bk9f8N/Gb8/0sO8HcNAH5r/o+egeGf 439mlp/7v34I/in+/yvbQE2KGlYbzHBuO6XKdaRJSGFJ6jJIxsHAYp8Wwa0p O8Y1SgtOgFWzzJmRTCJisDdGn5eJ9mDn6L7IVLlX7m0dfsW47BnMelYCp2RU zyE/cO2ouCZlNPJHQI3ihYpZ4h6vVauYk527uw/uG+5N69Ikomq37te1mIE9 JuECdxxoXeHgmU4nopVCxcq47FqmCZq8t2BIqh1Vz1P5QG83VIZeM2Dqqbw0 vQalKAZtCniolWUenkgR2KD7MBglUEE8hu3WZUA2H9Q2ArPbyJX0AaXFt45j 18akkXI1S2FcmRRVoaN24gv0dHnCdK07K9u7d4QWCc9DXqsqVLuLq21b0k2t W0zvoVEbV/dx2wzFta4AfScke3UilfBkKIO5+/p4CookwkyFaiqqYXvahVNB SlLbTEuebznm4pOK60xDZ3kK0atnt3yMc6aLnJdeIuoUEorpHPp+kYiDUMEE FWszAS3BKIjlnuFh9PzUuiTExI04ZJr3qNGozY1Bbig2FD+9xCIUu1ipavcK xgle1Ay32Wh/1ZEe4bo9lOlxI7C1L1dTdozeFxHY0JyC/3Wz3GdedW/qFVLj UHsNcbCpixqd2ZwosRkR8XqoyVg406EtrMG8RDId7e6jJEyQOf0v0IZlpsO0 Ms8iWcBTA7h9lwe0xiqKEZlyI1IV2WLAVQdFiv0Iqm+T0F8aiopjERZSYuEv XmIJC2zynfqrpS88wlRCJzj2XcbiMhF1bZ/HDAIwkWHnrBMexUD688H8LD6u E4FRp0N/QpXIchL6EPsxkX255EZAVOFuMpkDN8uUz0mwfIDJ4rXiarIHs2hV cgF1jJW6ZD2Qph54HQkjo9i9u80iaFCAYu0gJAzLG/OBBy50g5JJ6bTuD7zb bn4OeCRKd4X3WJzxyDRL8M5bhwXZueJRIUERHXhKalYUKGVNouFWIdF9enWt +xhnEWK75CA87ID7RuhqA+3s6XGmimXY8AXgpwHnQAsdUMQUW2oQMgjE7Mpk oqBgbtjVzhEm6uCklkMZUgV1PYRclh7as0f3KA98tmwMZ90if8yNhnBUCmK2 oDV1vifqPjpd9i9wsNg0KWTq2sbWjqfv0YY69OdfVzeiZA3U2a9nix8Cw9Zi Q3If5jkFrsCWay0U1yyYFFV3F0u2iI8qG8xGLNEt9IVj1nR26E3qxIVin3So IrHuHiH0lVrbPxiTmxcsfr5+X0t3G4SiwjwoZOXD/yraTkDh6v3xrHifssFD rHFUO6pTyJuwjfUlWvS2dPf12vLgS0qY8Wxivj42uy91bUea70wer+yilTeu j2E2HAebnz16Dt/Y+MsfDEIKvvjAzbCwMv/ms+COJNKJ422Lfk6j0+mqFy5W /iP56SYwi9uM05QzJ8FzfiaLyEZtNiXN+P1n4WW9CZsv4gFate0LPLS1ifcv Mq++hlYiSXOK2XzwfYuVW2kV2Rl7U5IsUA/P4UgJ03J4gjiqXpOOTVCuogdc 1ZyiAJxt9Keu+mSn4NauIQOP5yNwXIm6uqM0xlv9U2uUpxPzEcnAkF6tSbMU k5af73f9MfhN/bf7r+f/GGj/4f1vv+T/fvo//hj8k/7b/ZL/U7b4lv97+p7/ Y0RXv4Lu8LRAy5jtJ28thxJfYme0wBOP6XiLAB0VtAF9f9JIYKBiG5KxBCkD dRBPPH52XO96HBa+TkTTJh21dc8qsvo6xJuj4yBlZxUzu7OITj1cm3ELndPj yyX60+0Xev8Pn5gL4SlkISpfesCHJaC2+NZ7IJchjTTNLIboPMu/mAl/8Qxq 17HGTIUJU+GJhDEUy1Shs1jJF6N+UrWG3DtVyskwffZqXWt7DB9Gb5sKZXAC c3vq9QX1KqSskUG03W0aFtfeZ5OTbVCjdy8IZJNhoFIMKqZBKpIV2pRmuuwk NrcbnOj8s3fsM6QoLFdCP+GiPXDoWEUfsGW33vZzUzs3OUZKsZlRBdNrmFWx PVtu0nPxabXOLdM/i2c8q0yS6AhjDswxBpIMWEf6jqUQsaRInVRqm6TeeNAo j00mwqNhM4stQ2wy+Fk0vCTAk+fsOmalhXRKmt8DJ5YtZXOIlSkprQp4q6cJ Bol/hb0g8qqgTxyik0HGIiNiXyE/tFiPPbTavQeJpq7CqNCiD8O2hIGI2X/Y jIrBq9V2FsL+8MGZkvKTc0Dc4pGoTr3AZTVj64lvzZnLkdXS6Fx13VY1v5jn Yqu5oEp7UO1Ub6H3DW1CckzvgKBh+pL4aBYHMmJ4vTWRy8g7mDQQlcZ3NxRd YPnVCFcNgqSMpM1kE4dAAfxDtUdm8bGAeOPEXIM9WTXl4JcZw2+JWbxtZSrw he/p52/Mp5B6JQeyI4mpbJwjREsN5kyF1VqrceTEsPvlqi3Jw7iSddDL5iRN X8iKx+QuytG7KBXrF+oQDSoaw4ydf4EHprMdGpNxH/j8ioOyWXdGa766PiTL dyjngccaxJxjZnJHTOzwjlNJ3WwUk3JstqatzVtxbbRdzyi3wLe8fI/rk2NG MrRS+NFyjEM9xxsQhtDtPgPGZME3lYVVeOq6For4PnKTuIzmVhGQIUQDav1s RIuMuFBk0gdtBccklcIqw8FVZNBjvqNSQqdhkZJxXumvzPsks0lBrHMjmisB TtjdfWyB2cMxXWOUZfJDfbimN3TRnQkGNi0C3C6rpPKD4fP+551RajgC1WT1 RwB10tB9LPFNolz6UPT62FAbd6kd0K0qu0UcDEqIIk/a0eJA3gacC1hkyJ03 d5UXlgSkanK+ATCKCXSX+xYXNhYYlIZPr6yMOiVqtRdukqIcB3FuHFxXufUu AqG4/Ssm+tzwHY7kvNr697I034wv+WON3olS1tAdZj8Dx0qxQUWiFJL2lX+K JH8dq4BtEHAkzB1qWqdhd3qYXEOwXJXTUn3hITI5LNE4t6B+siTKlTXHlWWh qD8xMnjmB4lG5JmHdD90R+z0Hv5p19Ne9ZzHNfzVvBSC2OJdneVrjQb0nfoa ilqxE4EpBRFo4rSSU8uZdRYS3oONA2O0peOPAQdlO/dWU1kGj2tyg9nay954 YM4U8iD0ek668JSliy/C3pFaXqsdU+Myelq7oM2RMyX6UNYyLbEI5vvM4uya oFqQYB0X6Q32MXZKnZ8BlzDPhjLaTbNVIlj4tIsvHjXlRED68ebMQy/dRovC tRjQSSOvd8rEjiYdk3EmXCR1vtQwPMwE8Ic7ooErlS4uIR8hdfLysBZv0a67 kxqbiobPvh0bF+sITJaoV+E2vHZKSxXIXHV6Y8eywO8Z//QRvWKpf8FGy1wm IVPINJemhEbSdp6a1Nyx1hpUTE+aivwEChdGbzjLmJeJrWAHoVqqsq19Mcul 7F5Bt3KyERQJKCpMy18UaSjLmaNBKqe6Ykgs3JHzCN4Kvf3EeqtF87ZvQIU2 4I05dmpgLSlMlW6T+IeVFwqu49SPG0jTOC21iJAKt4/Vs9SfS5+1nNKv2u+h jOyhLC/DuDHkW1XdMmYsQ+tHOiY2Dp8X5N3WpGkscsSB546cgqe9uqzxT9xX Xa4x3zNCP+LuyKb4Rjt1aq51rqmO9HqMxTiCiFvmRl2sulwU3iPZy3XrjWn2 QYeU4L45SPZ6DOYRaS+IA5NlNRT9WP24QY01LklVxQrWmt4F/6ihayIOYjQy 3LNkdTJz2ZOG+kiC/L4a7Gbw8XWWe4kT0RlCByrOPSI9H/IMHOKfLV0/8Qfg 31n/Zfg7A8D/YP0n49dwEUD/B3qQ/0v8Xx7//Xv5/9/3BPwH6/+/PgI/+f8R +Dfnf3/XA/Af8E/HTP+T/x+Bf2f8/2f0/8y0P/n/Efgf+Ne30vsz/T+++7+w sPz0f/gh+Bf8f/v4T9n/8Qv/v/g//eT/v49f4f/7x39EGf/7/T9MTHQ//Z9+ CH6Lfz0ra2dbEyPj33Ptv+X/ycDM+E/t/xf9/zn//9+HwjfvRWsdPTMdIwPA Ox07gP53l2sTl1+cPqV07I11LAHyelb29gDL7//Y8fxyCLWVrRHAyhJC3sGS EkDHBpCycvxm9kn7zeaTgYWdlg1ARctES0sNASFq/92NU9cAoG/1ztLcSkf/ 68kNba0sAIb21uw0NFZ2dtR2RibfbLFprG2tTA307O1onAztaP56OA0EBP9f n0P2v/sbQMpP9t2gm+qbyyhA3sTcRM/KEiBsq2NtbKJnRwkQtdSjBgB4zc0B ct+OtwPIGdgZ2Doa6FP/DycB8Frq2xp8vQXCtg4Glro6esYGtl9rr2LlAPja LL5W2MDgu8+liZ29rYmuw1/dSu2sDO3ffTvAwVLfwPb/uHDSU9NB/MX/85tF qoSB3deS/2Kjag6QcdD9WleAhImegaWdATWEtCXgL/bids529gYWX+tua2D4 9QdfC/y7pvnNONzKksr8l5/Z0UgIy0hQfSvpm8/nt6K+HmD9i5GqgZM94N8v H4LfwNZex8Ty+wmsLA0sv94rUp1vZqCWVvbfbV+/fvfdy9TKwVbPgOz7HflL NfQhfrnyb1/bG9ha2P19uf+LC/7V+v/jeSD+cp6/PleGVl+r8K2Kv3Kvvt6q 786y1D9Ty3+H3+z/v7Z4IwNzKyPqX+j6TwaCv9X/s9Cx/GP/T/91wPjT/+uH 4Fv+1/17/vefmQZqirOyWheC6165IMs7iWL2nOmOuJ0vkqUeGyPAg0ixtUJ1 pV1I0GjwACzmn3w6AnqnIBpoHwnXzpz2OFR5MQhTq9ghOwuhSmleoWc9rsxN dvqSNTVbYsYDyXTKGOgBgqUOuJZWkSDdpxu4ntdl3LwdupaBWieG3Oz/ae/a o6K4zjixqdohIVqLRVPLEF8QHs77sRIMzwSCSAMqVqrM3LkDi8sund1VRIkn 0ARtOahEFBETEqsGUzw5x1jEiliSSLWKguZo0nKiNpqD8RlQmyMJvbMbCY+1 OXrAv+a3e+bsPO53v8ede8/9zex3zy9bsGhzI1U1OmxhwperRqQHLx9xskjK DniicEyh0PH+lNLz/PjHI7f9vQ6/kllYkln6vOx3/p2R4ktpFSfXPrduD597 qLXKe8FfpAsx69mOsLqKyARcrPzP1w2dIdsWqjkhLQEXYx9rOz793ScTy0fO jBZmjKd90nfSErk3yb9y8ajvlsaW+09tLpxiaj9xvWtd97Swt/7YXHd1hV/T N1FnhN//3FEmfNbc0fCTltX/GpfROr54aWN0THtB1bWZ50omlZl+t+/SQmfa BkfL6OKCteMaf+njXSf8OemjssCzzWsWHaq/1JMc+s8e+65V3R9XBwW390TP 3vmM7wGvlR9IWw6+c/vMe+sbozq2XpjvOy6zwzcg9HLQnNYNUty+mNkzruXX /HUiI3XXzCq8+12GF/8h+e+nrkec+uS/454Y5X++82L78YsZXd6vPSZUZhyd tHm+74Tw6o1pfjfOJGUz726q2Hry+pNftmh7t99tyy6vP41NDfI/B2XvNyNu VOVHBUyLWAPazi0uPrzsD0cmtswY+bQzodQc+unV3NM9v43YPbniqSkbq7sa Rhzak7jBe8Hc7NVrm9ICOqm4+tj0ebtYOt0qpwaUaKbY6qvPXHyxrWjJLWy6 szYu3m+6dOfuhYzQuI/HHkh7b863ZdqN7fv/VtTk98KKgPPzapM/X3Rg4s0E 78sFX1g3rYgZWbJ+7x2fCWv9Do64eTwz8cjY22/mE0XVmz7KLK9ddS5j1hvb sg+2bizyKXx/U0xDQem5n5bOTA/69nnn3dRTO8Z8c6wtMnPlWM27aeK6o03N ZV6jXwwJ3jN/WaX6ag0+KudXz36CUeX7xYTro3dduRz/9tfzbiUF99w+Fr9k zNtXS6xbJpw5uyM5563kFU9P7Zn3aaf8ek3xzi7lsFPF53bGRgav8638hWly 8JXw7bvl7KLY2n2+/juEr64FvlJJmK7tn/Xsrz8wnbhcMCf7lFd1Vcj017YG vXryT1Eb8rpaK8ry8by6ztP1PlVHmiadXX2puuE3//gw7kTTK0G36EW7xdr6 G+07nBULzwZNmvDVxKK4aCox03/yyvHbZtSEvrxit/cXtx6/c7Cx+Oap1ENH N6853DT7c7/Az7zStNDutmnmY3Nf/1lqZOWW/CXpR0PM3aPibq9sTfF+iPu/ t6PX134e8t7FjQeb/9MuvlDnf4353/CjX/yHYe1vHQ+x/jdFM0b+t0cBj/Ef Yt79weNP8zRnrP/+KOAx/pahbQAPcf+TJGXE/1GgN/4xsVHxkUnD4vEH4395 vb24+n9j/B9+DIw/sFkdmm1oB94f538Hxp/m9Pgb8//hR7Kb+jXh9xoC9j2B acKpMCKMpEJJLAUCh+sIOg0tWLJmtmlmx3ITDvMcmoRFaiDL7EDXODUkx0wL HBYDc6FVsZtwNKIAThcb4qoAD4x4ziWXCMKibVbVYgYOu+n7U+Hh907FW1FQ LBaohKaY85FMgcBmS2arTlBCzdSflA4fzEpHYCkultItGCljB5o5121CbJ4D aQYV1yk3i4vqcpiBrqomaWaok54KngUlBTkC6/ULrt8ZSAG7i5L0dLGLXbTj Vgh1+TpTrLvLlovhuZotU5Ny7PiyLDPIwnOkJRB32qHOb8JB+tjDcDzOpuGJ Zqszr7doCOaqV7EBZw606oSsmzfFAXIUHpkcj5vdmmlQJz7dMpHLoKZKAIbg SDJSFcNTXojH41+OT3Mxrchu2WxBofzhSl2MZLHb9IqXmhWdKcfRN9qpaaha y3LcZkUbpDUVom9pl/1pcSm43Zmba9McHg3C8FSk2X2q1nWXnWYL0k+2LYUu I9y297HQjvTCdJ+5nkr0+tPuRO6U7HiealecObmBQlCI/luDdodNg2jXpR46 shgdRLsG9zsQA/v/HIW1O3OGNvHmj/X/HMX26f9Jvf9nGd7o/x8FgKw/awUK y7E0LxGqwCtAFgWeJAkAZBniuP5gwGwFFqcC3a+F9LmxszAe0CJNECqQAcGx AkcDhlYh5FFhluFUwUN5d0rZLIxkaRJKlCpDGcgMTdEkAWVJ4Rg0/FP8vaL9 5qUYQ/OqrKgKgCJJygxPMQLgocCqkGVoQFCDy1gkTKApkZNoqAqKKtEKSwAK TTNYyACJFylZdBcakPy239oXGEtQgOcAy5EiB2ig0pIKWF7iVd1SkSQ8iuif Ph+jOUUGrAJUnmZoSMkkUNFHEVUaish1qkcZA1NwY4TAAUbhke3IApZCVrA0 5AAkJJkmAct6lNIvkS9GE4ATGMCwJC1yJIFcQIiiClDEeUElaE+KDEgGismC AIFIURQgGE4gGFYRZIngUTuieJZRPGkxKJ8YRigoEiqkRcAiJRRRJFlZVClR oSAjS9L/EdInKQGmCCxqCxzNigCVIhWS0NkjVRBkVZBkkb+/lHt/bcQgp4qi xKo8S8osGruAIAksTSB9REpC7aWvCM9vR2AKxUoSUGUgEKqqSgJNcyoQIWQF UVF5hb+/iMEP2IxByoABAwYMGDBgwIABAwYMDDX+B+0UUvIA8AAA --=_gBBFr7Ir9EOA20-- From owner-linux-xfs@oss.sgi.com Tue Oct 8 05:28:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 05:28:48 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98CSftG019456 for ; Tue, 8 Oct 2002 05:28:42 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 FAA01284 for ; Tue, 8 Oct 2002 05:28:40 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g98CRiIx007406 for ; Tue, 8 Oct 2002 14:27:44 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g98CRiXN007405 for linux-xfs@oss.sgi.com; Tue, 8 Oct 2002 14:27:44 +0200 Date: Tue, 8 Oct 2002 14:27:44 +0200 Message-Id: <200210081227.g98CRiXN007405@lab343.munich.sgi.com> Subject: TAKE - cleanup vn_revalidate To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs There are certain fields in the Linux inode that are constant over it's lifetime. We don't need to update those from the XFS inode ever. Date: Tue Oct 8 05:27:53 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:129315a linux/fs/xfs/linux/xfs_vnode.c - 1.99 - Don't update i_rdev and i_generation in vn_revalidate. From owner-linux-xfs@oss.sgi.com Tue Oct 8 07:05:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 07:05:54 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98E5otG021919 for ; Tue, 8 Oct 2002 07:05:51 -0700 Received: from pc8950.physik.uni-regensburg.de (pc8950.physik.uni-regensburg.de [132.199.98.152]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g98E5nK10276; Tue, 8 Oct 2002 16:05:49 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc8950 ident=guc28561) by pc8950.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yuzd-0001jN-00; Tue, 08 Oct 2002 16:05:49 +0200 Date: Tue, 8 Oct 2002 16:05:48 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Cc: nathans@sgi.com Subject: Re: tar xfs problem ? was: Re: xfs_fsr broken again? Message-ID: <20021008160548.A4467@pc8950.uni-regensburg.de> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> <20021008181533.A254596@wobbly.melbourne.sgi.com> <20021008134737.A8760@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20021008134737.A8760@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Tue, Oct 08, 2002 at 13:47:37 +0200 X-Mailer: Balsa 1.2.4 Lines: 29 X-archive-position: 869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 08 Oct 2002 13:47:37 Christian Guggenberger wrote: > On 08 Oct 2002 10:15:33 Nathan Scott wrote: >> On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: >> > Hi, >> > >> > I have the same problems here on my debian/unstable box. According to >> > Nathan Scott the builds are fine on his box... maybe Nathan should >> check >> > again?! >> > ... >> > But you can use the latest xfsprogs, xfsdump and attr binary packages >> from >> > debian/unstable, they contain the fixes Eric checked in last week. >> >> *cough* -- those would be the packages I built on my (debian/unstable) >> laptop just yesterday, right? ;-) >> > It seems to be a problem, when building those debian packages on a > xfs-Partition... the Problem seems to be in tar... I get proper builds > on an ext3 filesystem... > .... i just checked again on a system running CVS Kernel of September, 2nd; this machine has no Problems with "false" symlink names in a tarred archive. My previous tests (which showed those symlink problems in tar archives) had been run on today's CVS Kernel ... Christian From owner-linux-xfs@oss.sgi.com Tue Oct 8 08:22:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 08:22:31 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FMStG022982 for ; Tue, 8 Oct 2002 08:22:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA29913; Tue, 8 Oct 2002 10:22:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA29220; Tue, 8 Oct 2002 10:22:12 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98FKqM14543; Tue, 8 Oct 2002 10:20:52 -0500 Subject: Re: tar xfs problem ? was: Re: xfs_fsr broken again? From: Steve Lord To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com, Nathan Scott In-Reply-To: <20021008160548.A4467@pc8950.uni-regensburg.de> References: <20021008065719.GA999@psychedelic.baana.suomi.net> <20021008094316.A4351@pc9391.uni-regensburg.de> <20021008181533.A254596@wobbly.melbourne.sgi.com> <20021008134737.A8760@pc9391.uni-regensburg.de> <20021008160548.A4467@pc8950.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Oct 2002 10:20:52 -0500 Message-Id: <1034090452.7497.19.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-10-08 at 09:05, Christian Guggenberger wrote: > On 08 Oct 2002 13:47:37 Christian Guggenberger wrote: > > On 08 Oct 2002 10:15:33 Nathan Scott wrote: > >> On Tue, Oct 08, 2002 at 09:43:16AM +0200, Christian Guggenberger wrote: > >> > Hi, > >> > > >> > I have the same problems here on my debian/unstable box. According to > >> > Nathan Scott the builds are fine on his box... maybe Nathan should > >> check > >> > again?! > >> > ... > >> > But you can use the latest xfsprogs, xfsdump and attr binary packages > >> from > >> > debian/unstable, they contain the fixes Eric checked in last week. > >> > >> *cough* -- those would be the packages I built on my (debian/unstable) > >> laptop just yesterday, right? ;-) > >> > > It seems to be a problem, when building those debian packages on a > > xfs-Partition... the Problem seems to be in tar... I get proper builds > > on an ext3 filesystem... > > > .... > > i just checked again on a system running CVS Kernel of September, 2nd; > this machine has no Problems with "false" symlink names in a tarred > archive. My previous tests (which showed those symlink problems in tar > archives) had been run on today's CVS Kernel ... > > Christian > The length of a symlink appears to be getting messed up. I will take a look since I made some changes in this area recently. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 8 08:33:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 08:33:27 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FXMtG023809 for ; Tue, 8 Oct 2002 08:33:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA85747 for ; Tue, 8 Oct 2002 10:33:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA77989 for ; Tue, 8 Oct 2002 10:33:17 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98FVvU15335; Tue, 8 Oct 2002 10:31:57 -0500 Message-Id: <200210081531.g98FVvU15335@jen.americas.sgi.com> Date: Tue, 8 Oct 2002 10:31:57 -0500 Subject: TAKE - fix xfs symlink creation To: linux-xfs@oss.sgi.com X-archive-position: 871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs ensure inode size is correct after making a symlink. This has been in the code for a few days, should fix debian package creation. Date: Tue Oct 8 08:31:58 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129340a linux/fs/xfs/linux/xfs_iops.c - 1.177 - update the linux inode size with the xfs inode size after symlink creation. From owner-linux-xfs@oss.sgi.com Tue Oct 8 08:34:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 08:34:42 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FYZtG023896 for ; Tue, 8 Oct 2002 08:34:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA30703; Tue, 8 Oct 2002 10:34:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA26417; Tue, 8 Oct 2002 10:34:28 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98FX8Y15505; Tue, 8 Oct 2002 10:33:08 -0500 Subject: Re: dir hashes From: Steve Lord To: Mihai RUSU Cc: Linux XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Oct 2002 10:33:08 -0500 Message-Id: <1034091188.7497.28.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-10-07 at 19:30, Mihai RUSU wrote: > Hi > > I have recently run into some performance issues with XFS and directories > with lots (>1k) entries. I knew XFS was immune to this sort of problems > (if I remember well only ext2/ext3 did linear search in directories and > XFS/ReiserFS/JFS had hashes of some sort). Is it important to devide > directories with lots of entries (some with 25k subdirectories) for XFS ? Performance issues on lookup, or on modifications to the dir? Yes we do have hashing in directories, which means lookups do not need to walk the whole dir. Larger directories are more work to process, and XFS will slowdown on creation and removal for large directories, the btree code is to blame here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 8 08:55:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 08:55:17 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FtEtG024870 for ; Tue, 8 Oct 2002 08:55:15 -0700 Received: from pc8950.physik.uni-regensburg.de (pc8950.physik.uni-regensburg.de [132.199.98.152]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g98FssK26280; Tue, 8 Oct 2002 17:54:54 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc8950 ident=guc28561) by pc8950.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17ywhB-0002jf-00; Tue, 08 Oct 2002 17:54:53 +0200 Date: Tue, 8 Oct 2002 17:54:53 +0200 From: Christian Guggenberger To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix xfs symlink creation Message-ID: <20021008175453.C4467@pc8950.uni-regensburg.de> References: <200210081531.g98FVvU15335@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <200210081531.g98FVvU15335@jen.americas.sgi.com>; from lord@sgi.com on Tue, Oct 08, 2002 at 17:31:57 +0200 X-Mailer: Balsa 1.2.4 Lines: 9 X-archive-position: 873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 08 Oct 2002 17:31:57 Steve Lord wrote: > ensure inode size is correct after making a symlink. This has been > in the code for a few days, should fix debian package creation. This "nasty" code you mentioned, is this in the first 1.2 prerelease (October, 4th), too? Christian From owner-linux-xfs@oss.sgi.com Tue Oct 8 08:57:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 08:57:31 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FvRtG024988 for ; Tue, 8 Oct 2002 08:57:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA43865; Tue, 8 Oct 2002 10:57:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA77278; Tue, 8 Oct 2002 10:57:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98Fu1A16085; Tue, 8 Oct 2002 10:56:01 -0500 Subject: Re: TAKE - fix xfs symlink creation From: Steve Lord To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021008175453.C4467@pc8950.uni-regensburg.de> References: <200210081531.g98FVvU15335@jen.americas.sgi.com> <20021008175453.C4467@pc8950.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Oct 2002 10:56:01 -0500 Message-Id: <1034092561.16054.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-10-08 at 10:54, Christian Guggenberger wrote: > On 08 Oct 2002 17:31:57 Steve Lord wrote: > > ensure inode size is correct after making a symlink. This has been > > in the code for a few days, should fix debian package creation. > > This "nasty" code you mentioned, is this in the first 1.2 prerelease > (October, 4th), too? I do not think it is. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 8 09:19:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 09:19:34 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98GJMtG026092 for ; Tue, 8 Oct 2002 09:19:25 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id CAA04822; Wed, 9 Oct 2002 02:04:07 +0930 Message-ID: <3DA308E0.75DF5DA3@rebel.net.au> Date: Wed, 09 Oct 2002 02:03:36 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.19-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> <1033995657.1054.25.camel@laptop.americas.sgi.com> <3DA24D3C.74D34374@adam.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs Hmmm... > The make continues to the end so I assume that unless the XFS stuff is > silently crashing (weird) it is being made. It doesn't like initial ramdisks. If I don't use an initrd then I don't get any problems at all. I have ramdisk support and initrd support compiled into this kernel. Has anyone seen this behaviour before? DSL -- Somewhere where I hope to find someone Still I find myself near you If I hear the words I'll go. (from the musical Martin Guerre) From owner-linux-xfs@oss.sgi.com Tue Oct 8 09:45:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 09:45:38 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98GjRtG005964 for ; Tue, 8 Oct 2002 09:45:33 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id B490B1E3464; Tue, 8 Oct 2002 09:45:20 -0700 (PDT) Date: Tue, 8 Oct 2002 09:45:20 -0700 From: Chris Wedgwood To: David Lloyd Cc: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System Message-ID: <20021008164520.GA3819@tapu.f00f.org> References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> <1033995657.1054.25.camel@laptop.americas.sgi.com> <3DA24D3C.74D34374@adam.com.au> <3DA308E0.75DF5DA3@rebel.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA308E0.75DF5DA3@rebel.net.au> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Oct 09, 2002 at 02:03:36AM +0930, David Lloyd wrote: > It doesn't like initial ramdisks. "Doesn't like" means what? It won't build? --cw From owner-linux-xfs@oss.sgi.com Tue Oct 8 09:49:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 09:49:10 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98Gn7tG006111 for ; Tue, 8 Oct 2002 09:49:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA52433 for ; Tue, 8 Oct 2002 11:48:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA29657 for ; Tue, 8 Oct 2002 11:48:47 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98GlRt18170; Tue, 8 Oct 2002 11:47:27 -0500 Message-Id: <200210081647.g98GlRt18170@jen.americas.sgi.com> Date: Tue, 8 Oct 2002 11:47:27 -0500 Subject: TAKE - dmapi device stat fix To: linux-xfs@oss.sgi.com X-archive-position: 877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fix dmapi's stat of a dev code (ip_to_stat), we are going back to user space and need to return the correct dev_t format. Date: Tue Oct 8 09:47:22 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129349a linux/fs/xfs/xfs_dmapi.c - 1.80 - convert kdev_t to a number before returning to user space From owner-linux-xfs@oss.sgi.com Tue Oct 8 10:05:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 10:05:25 -0700 (PDT) Received: from rebel.net.au (IDENT:root@ftp.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98H5GtG007242 for ; Tue, 8 Oct 2002 10:05:18 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id CAA05776; Wed, 9 Oct 2002 02:48:58 +0930 Message-ID: <3DA31354.CC0C46F9@rebel.net.au> Date: Wed, 09 Oct 2002 02:48:12 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.19-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wedgwood CC: David Lloyd , Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Kernel 2.4.19-CVS Unable to Mount Root File System References: <3DA126E0.A7821938@adam.com.au> <20021007060712.GA22104@tapu.f00f.org> <3DA128C4.D77A7CD0@adam.com.au> <20021007061248.GB22104@tapu.f00f.org> <3DA12AFB.A680311D@adam.com.au> <1033995657.1054.25.camel@laptop.americas.sgi.com> <3DA24D3C.74D34374@adam.com.au> <3DA308E0.75DF5DA3@rebel.net.au> <20021008164520.GA3819@tapu.f00f.org> Content-Type: multipart/mixed; boundary="------------14B734D8D79587217D00AA2E" X-archive-position: 878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------14B734D8D79587217D00AA2E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, > > It doesn't like initial ramdisks. > > "Doesn't like" means what? It won't build? XFS: bad magic number XFS: SB validate failed Kernel Panic. VFS: Unable to mount root fs on 03:02 ...the moment I mention an initrd it does that. The moment I either comment the line out in lilo or type "linux noinitrd" it boots straight through. I've made my ramdisk with: mkinitrd /boot/kernel-2.4.19-XFS_CVS.img 2.4.19-xfs DSL -- Somewhere where I hope to find someone Still I find myself near you If I hear the words I'll go. (from the musical Martin Guerre) --------------14B734D8D79587217D00AA2E Content-Type: text/x-vcard; charset=us-ascii; name="lloy0076.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Lloyd Content-Disposition: attachment; filename="lloy0076.vcf" begin:vcard n:Lloyd;David tel;cell:+61 4 02 44 09 93 tel;home:+61 8 8165 0305 x-mozilla-html:FALSE url:http://www.rebel.net.au/~lloy0076 adr:;;131 St Bernards Road;Rostrevor;South Australia;5073;Australia version:2.1 email;internet:lloy0076@adam.com.au x-mozilla-cpt:;0 fn:David Lloyd end:vcard --------------14B734D8D79587217D00AA2E-- From owner-linux-xfs@oss.sgi.com Tue Oct 8 10:10:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 10:10:57 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98HArtG007538 for ; Tue, 8 Oct 2002 10:10:55 -0700 Received: from pc8950.physik.uni-regensburg.de (pc8950.physik.uni-regensburg.de [132.199.98.152]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g98HAiQ28442; Tue, 8 Oct 2002 19:10:44 +0200 (MEST) Received: from loopback ([127.0.0.1] helo=pc8950 ident=guc28561) by pc8950.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17yxsa-0003YV-01; Tue, 08 Oct 2002 19:10:44 +0200 Date: Tue, 8 Oct 2002 19:10:43 +0200 From: Christian Guggenberger To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix xfs symlink creation Message-ID: <20021008191043.A12310@pc8950.uni-regensburg.de> References: <200210081531.g98FVvU15335@jen.americas.sgi.com> <20021008175453.C4467@pc8950.uni-regensburg.de> <1034092561.16054.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1034092561.16054.0.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Oct 08, 2002 at 17:56:01 +0200 X-Mailer: Balsa 1.2.4 Lines: 16 X-archive-position: 879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 08 Oct 2002 17:56:01 Steve Lord wrote: > On Tue, 2002-10-08 at 10:54, Christian Guggenberger wrote: > > On 08 Oct 2002 17:31:57 Steve Lord wrote: > > > ensure inode size is correct after making a symlink. This has been > > > in the code for a few days, should fix debian package creation. > > > > This "nasty" code you mentioned, is this in the first 1.2 prerelease > > (October, 4th), too? > > I do not think it is. > yep, just tested, it isn't in in 1.2 pre1. thx Christian From owner-linux-xfs@oss.sgi.com Tue Oct 8 10:33:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 10:33:58 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98HXqtG008461 for ; Tue, 8 Oct 2002 10:33:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA28660 for ; Tue, 8 Oct 2002 12:33:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA04587 for ; Tue, 8 Oct 2002 12:33:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98HWP419058; Tue, 8 Oct 2002 12:32:25 -0500 Message-Id: <200210081732.g98HWP419058@jen.americas.sgi.com> Date: Tue, 8 Oct 2002 12:32:25 -0500 Subject: TAKE - xfs components of the 2.5.41 merge. X-archive-position: 880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs CONTRIBUTED: Makefile format changes from Kai Germaschewski and CONTRIBUTED: direct I/O parameter changes from Andrew Morton Remainder from Christoph. Date: Tue Oct 8 10:33:15 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:129356a linux/fs/xfs/xfs_log.c - 1.256 linux/fs/xfs/xfs_log_priv.h - 1.85 - use new workqueue infrastructure linux/fs/xfs/Makefile - 1.159 - no longer descending to directories during make linux/fs/xfs/pagebuf/page_buf.c - 1.67 linux/fs/xfs/pagebuf/page_buf.h - 1.48 - use new workqueue infrastructure linux/fs/xfs/linux/xfs_aops.c - 1.11 - linvfs_direct_IO takes a file rather than an inode pointer From owner-linux-xfs@oss.sgi.com Tue Oct 8 11:49:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 11:49:43 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98InUtG010682 for ; Tue, 8 Oct 2002 11:49:35 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.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 LAA07201 for ; Tue, 8 Oct 2002 11:11:00 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA03405 for ; Tue, 8 Oct 2002 13:01:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA25285 for ; Tue, 8 Oct 2002 13:01:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g98Hxpm19159; Tue, 8 Oct 2002 12:59:51 -0500 Message-Id: <200210081759.g98Hxpm19159@jen.americas.sgi.com> Date: Tue, 8 Oct 2002 12:59:51 -0500 Subject: TAKE - merge up to 2.5.41 To: linux-xfs@oss.sgi.com X-archive-position: 881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Some problems with small block size filesystems in here, O_DIRECT mostly. Date: Tue Oct 8 10:39:47 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:129361a linux/sound/usb/usbquirks.h - 1.1 linux/sound/usb/usbmixer.c - 1.1 linux/sound/usb/usbmidi.c - 1.1 linux/sound/usb/usbaudio.h - 1.1 linux/Documentation/filesystems/ext3.txt - 1.1 linux/sound/usb/usbaudio.c - 1.1 linux/sound/usb/Makefile - 1.1 linux/sound/usb/Config.in - 1.1 linux/sound/usb/Config.help - 1.1 linux/sound/pci/via82xx.c - 1.1 linux/sound/pci/ice1712/ice1712.h - 1.1 linux/sound/pci/ice1712/ice1712.c - 1.1 linux/sound/pci/ice1712/hoontech.h - 1.1 linux/sound/pci/ice1712/hoontech.c - 1.1 linux/sound/pci/ice1712/ews.h - 1.1 linux/sound/pci/ice1712/ews.c - 1.1 linux/sound/pci/ice1712/delta.h - 1.1 linux/sound/pci/ice1712/delta.c - 1.1 linux/sound/pci/ice1712/ak4524.c - 1.1 linux/sound/pci/ice1712/Makefile - 1.1 linux/drivers/isdn/i4l/isdn_fsm.c - 1.1 linux/drivers/bluetooth/hci_bcsp.c - 1.1 linux/mm/truncate.c - 1.1 linux/net/x25/x25_proc.c - 1.1 linux/drivers/bluetooth/hci_bcsp.h - 1.1 linux/include/asm-s390x/kmap_types.h - 1.1 linux/drivers/char/amd768_rng.c - 1.1 linux/include/asm-s390/kmap_types.h - 1.1 linux/fs/nfs/direct.c - 1.1 linux/drivers/char/scx200_gpio.c - 1.1 linux/net/llc/llc_proc.c - 1.1 linux/net/ipx/ipx_proc.c - 1.1 linux/drivers/char/scx200_wdt.c - 1.1 linux/arch/i386/kernel/scx200.c - 1.1 linux/drivers/video/font_mini_4x6.c - 1.1 linux/net/ipx/ChangeLog - 1.1 linux/drivers/usb/serial/console.c - 1.1 linux/drivers/usb/misc/usbtest.c - 1.1 linux/drivers/scsi/nsp32_io.h - 1.1 linux/drivers/scsi/nsp32_debug.c - 1.1 linux/drivers/scsi/nsp32.h - 1.1 linux/drivers/scsi/nsp32.c - 1.1 linux/drivers/scsi/aacraid/sa.c - 1.1 linux/drivers/scsi/aacraid/rx.c - 1.1 linux/drivers/scsi/aacraid/linit.c - 1.1 linux/drivers/scsi/aacraid/dpcsup.c - 1.1 linux/drivers/scsi/aacraid/commsup.c - 1.1 linux/drivers/scsi/aacraid/comminit.c - 1.1 linux/drivers/scsi/aacraid/commctrl.c - 1.1 linux/include/linux/scx200.h - 1.1 linux/include/linux/scx200_gpio.h - 1.1 linux/drivers/scsi/aacraid/aacraid.h - 1.1 linux/drivers/scsi/aacraid/aachba.c - 1.1 linux/drivers/i2c/scx200_acb.c - 1.1 linux/drivers/i2c/scx200_i2c.c - 1.1 linux/drivers/scsi/aacraid/TODO - 1.1 linux/drivers/scsi/aacraid/README - 1.1 linux/drivers/scsi/aacraid/Makefile - 1.1 linux/drivers/mtd/maps/scx200_docflash.c - 1.1 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.1 linux/drivers/isdn/i4l/isdn_fsm.h - 1.1 linux/net/bluetooth/bnep/netdev.c - 1.1 linux/include/linux/workqueue.h - 1.1 linux/net/bluetooth/rfcomm/tty.c - 1.1 linux/net/bluetooth/rfcomm/sock.c - 1.1 linux/net/bluetooth/rfcomm/crc.c - 1.1 linux/net/bluetooth/rfcomm/core.c - 1.1 linux/net/bluetooth/rfcomm/Makefile - 1.1 linux/net/bluetooth/rfcomm/Config.in - 1.1 linux/net/bluetooth/rfcomm/Config.help - 1.1 linux/net/bluetooth/bnep/sock.c - 1.1 linux/net/bluetooth/bnep/core.c - 1.1 linux/net/bluetooth/bnep/crc32.h - 1.1 linux/net/bluetooth/bnep/crc32.c - 1.1 linux/net/bluetooth/bnep/Config.help - 1.1 linux/net/bluetooth/bnep/bnep.h - 1.1 linux/net/bluetooth/bnep/Makefile - 1.1 linux/arch/s390x/kernel/ptrace32.h - 1.1 linux/net/bluetooth/bnep/Config.in - 1.1 linux/include/net/llc_proc.h - 1.1 linux/include/net/bluetooth/rfcomm.h - 1.1 linux/include/sound/sscape_ioctl.h - 1.1 linux/net/appletalk/atalk_proc.c - 1.1 linux/arch/sparc/mm/highmem.c - 1.1 linux/kernel/workqueue.c - 1.1 linux/scripts/lxdialog/Makefile - 1.7 linux/scripts/Makefile - 1.10 linux/net/x25/x25_route.c - 1.10 linux/net/x25/af_x25.c - 1.31 linux/net/x25/Makefile - 1.6 linux/net/wanrouter/wanproc.c - 1.24 linux/net/socket.c - 1.42 linux/net/packet/af_packet.c - 1.35 linux/net/netsyms.c - 1.52 linux/net/ipx/af_ipx.c - 1.31 linux/net/ipx/Makefile - 1.9 linux/net/ipv6/udp.c - 1.31 linux/net/ipv6/sit.c - 1.23 linux/net/ipv6/route.c - 1.23 linux/net/ipv6/reassembly.c - 1.13 linux/net/ipv6/mcast.c - 1.20 linux/net/ipv6/ipv6_sockglue.c - 1.17 linux/net/ipv6/ip6_output.c - 1.15 linux/net/ipv6/ip6_fib.c - 1.12 linux/net/ipv6/icmp.c - 1.20 linux/net/ipv6/datagram.c - 1.11 linux/net/ipv6/af_inet6.c - 1.26 linux/net/ipv6/addrconf.c - 1.27 linux/net/ipv4/tcp_ipv4.c - 1.49 linux/net/ipv4/tcp_input.c - 1.42 linux/net/ipv4/route.c - 1.36 linux/net/ipv4/ipmr.c - 1.22 linux/net/ipv4/ipip.c - 1.23 linux/net/ipv4/ipconfig.c - 1.34 linux/net/ipv4/ip_output.c - 1.35 linux/net/ipv4/ip_gre.c - 1.22 linux/net/ipv4/igmp.c - 1.19 linux/net/ipv4/devinet.c - 1.18 linux/net/ipv4/af_inet.c - 1.40 linux/net/ethernet/eth.c - 1.9 linux/net/core/profile.c - 1.9 linux/net/core/dev.c - 1.62 linux/net/bridge/br.c - 1.24 linux/net/appletalk/sysctl_net_atalk.c - 1.4 linux/net/appletalk/ddp.c - 1.23 linux/net/appletalk/aarp.c - 1.15 linux/net/appletalk/Makefile - 1.6 linux/mm/vmscan.c - 1.116 linux/mm/swapfile.c - 1.66 linux/mm/swap_state.c - 1.51 linux/mm/swap.c - 1.27 linux/mm/page_io.c - 1.31 linux/mm/page_alloc.c - 1.95 linux/mm/mprotect.c - 1.35 linux/mm/mmap.c - 1.62 linux/mm/memory.c - 1.95 linux/mm/filemap.c - 1.137 linux/mm/Makefile - 1.19 linux/kernel/sys.c - 1.42 linux/kernel/signal.c - 1.44 linux/kernel/sched.c - 1.85 linux/kernel/ksyms.c - 1.169 linux/kernel/kmod.c - 1.26 linux/kernel/fork.c - 1.73 linux/kernel/Makefile - 1.37 linux/init/main.c - 1.92 linux/include/video/font.h - 1.3 linux/include/net/x25.h - 1.13 linux/include/net/ipx.h - 1.10 linux/include/linux/zorro.h - 1.9 linux/include/linux/wanpipe.h - 1.8 linux/include/linux/types.h - 1.9 linux/include/linux/tty_flip.h - 1.5 linux/include/linux/tty.h - 1.18 linux/include/linux/tqueue.h - 1.14 linux/include/linux/timer.h - 1.17 linux/include/linux/swap.h - 1.66 linux/include/linux/sunrpc/types.h - 1.5 linux/include/linux/sunrpc/sched.h - 1.12 linux/include/linux/sunrpc/debug.h - 1.5 linux/include/linux/stallion.h - 1.5 linux/include/linux/serialP.h - 1.16 linux/include/linux/serial167.h - 1.4 linux/include/linux/sched.h - 1.87 linux/include/linux/pipe_fs_i.h - 1.9 linux/include/linux/pci.h - 1.65 linux/include/linux/pagemap.h - 1.48 linux/include/linux/nfs_fs.h - 1.26 linux/include/linux/netdevice.h - 1.39 linux/include/linux/ncp_fs_sb.h - 1.9 linux/include/linux/nbd.h - 1.18 linux/include/linux/mm.h - 1.103 linux/include/linux/list.h - 1.21 linux/include/linux/kernel_stat.h - 1.12 linux/include/linux/kbd_kern.h - 1.10 linux/include/linux/istallion.h - 1.4 linux/include/linux/isicom.h - 1.5 linux/include/linux/isdn_ppp.h - 1.12 linux/include/linux/isdn.h - 1.27 linux/include/linux/if_eql.h - 1.6 linux/include/linux/hpfs_fs_sb.h - 1.4 linux/include/linux/hayesesp.h - 1.3 linux/include/linux/fs.h - 1.193 linux/include/linux/cyclades.h - 1.9 linux/include/linux/blkdev.h - 1.72 linux/include/linux/atalk.h - 1.7 linux/include/linux/amifd.h - 1.4 linux/include/asm-sparc64/visasm.h - 1.5 linux/include/asm-sparc64/upa.h - 1.4 linux/include/asm-sparc64/unistd.h - 1.26 linux/include/asm-sparc64/uaccess.h - 1.8 linux/include/asm-sparc64/system.h - 1.24 linux/include/asm-sparc64/spitfire.h - 1.9 linux/include/asm-sparc64/spinlock.h - 1.14 linux/include/asm-sparc64/smp.h - 1.17 linux/include/asm-sparc64/siginfo.h - 1.11 linux/include/asm-sparc64/sbus.h - 1.8 linux/include/asm-sparc64/pstate.h - 1.3 linux/include/asm-sparc64/psrcompat.h - 1.3 linux/include/asm-sparc64/pgtable.h - 1.39 linux/include/asm-sparc64/page.h - 1.20 linux/include/asm-sparc64/irq.h - 1.14 linux/include/asm-sparc64/fpumacro.h - 1.4 linux/include/asm-sparc64/delay.h - 1.9 linux/include/asm-sparc64/checksum.h - 1.9 linux/include/asm-sparc/unistd.h - 1.24 linux/include/asm-ppc/unistd.h - 1.27 linux/include/asm-mips/unistd.h - 1.14 linux/include/asm-m68k/unistd.h - 1.16 linux/include/asm-i386/unistd.h - 1.28 linux/include/asm-arm/unistd.h - 1.24 linux/include/asm-alpha/unistd.h - 1.23 linux/fs/vfat/namei.c - 1.34 linux/fs/smbfs/sock.c - 1.15 linux/fs/smbfs/inode.c - 1.42 linux/fs/pipe.c - 1.34 linux/fs/nfs/write.c - 1.43 linux/fs/nfs/read.c - 1.35 linux/fs/nfs/nfs3xdr.c - 1.16 linux/fs/nfs/nfs2xdr.c - 1.19 linux/fs/nfs/inode.c - 1.54 linux/fs/nfs/file.c - 1.36 linux/fs/nfs/dir.c - 1.45 linux/fs/nfs/Makefile - 1.9 linux/fs/ncpfs/sock.c - 1.15 linux/fs/ncpfs/inode.c - 1.38 linux/fs/inode.c - 1.83 linux/fs/fcntl.c - 1.27 linux/fs/fat/inode.c - 1.48 linux/fs/ext2/inode.c - 1.55 linux/fs/buffer.c - 1.137 linux/fs/block_dev.c - 1.64 linux/drivers/zorro/zorro.c - 1.12 linux/drivers/zorro/Makefile - 1.11 linux/drivers/video/fonts.c - 1.6 linux/drivers/video/Makefile - 1.45 linux/drivers/video/Config.in - 1.40 linux/drivers/usb/Makefile - 1.57 linux/drivers/scsi/wd7000.h - 1.6 linux/drivers/scsi/wd7000.c - 1.17 linux/drivers/scsi/st.c - 1.53 linux/drivers/scsi/sg.c - 1.39 linux/drivers/scsi/sd.h - 1.9 linux/drivers/scsi/sd.c - 1.73 linux/drivers/scsi/scsi_error.c - 1.31 linux/drivers/scsi/scsi.h - 1.34 linux/drivers/scsi/scsi.c - 1.60 linux/drivers/scsi/ppa.c - 1.18 linux/drivers/scsi/megaraid.c - 1.36 linux/drivers/scsi/mac_NCR5380.c - 1.6 linux/drivers/scsi/inia100.c - 1.21 linux/drivers/scsi/imm.c - 1.18 linux/drivers/scsi/hosts.h - 1.25 linux/drivers/scsi/hosts.c - 1.32 linux/drivers/scsi/g_NCR5380.h - 1.7 linux/drivers/scsi/g_NCR5380.c - 1.16 linux/drivers/scsi/atari_NCR5380.c - 1.7 linux/drivers/scsi/aha152x.c - 1.31 linux/drivers/scsi/NCR53c406a.c - 1.14 linux/drivers/scsi/NCR5380.h - 1.5 linux/drivers/scsi/NCR5380.c - 1.11 linux/drivers/scsi/Makefile - 1.40 linux/drivers/scsi/Config.in - 1.32 linux/drivers/scsi/53c7,8xx.c - 1.21 linux/drivers/sbus/sbus.c - 1.19 linux/drivers/sbus/Makefile - 1.9 linux/drivers/pci/compat.c - 1.10 linux/drivers/pci/Makefile - 1.25 linux/drivers/net/tlan.h - 1.14 linux/drivers/net/tlan.c - 1.31 linux/drivers/net/plip.c - 1.25 linux/drivers/net/hp100.c - 1.23 linux/drivers/net/hamradio/dmascc.c - 1.12 linux/drivers/net/hamradio/baycom_epp.c - 1.22 linux/drivers/net/eql.c - 1.16 linux/drivers/net/cs89x0.c - 1.26 linux/drivers/net/atp.c - 1.20 linux/drivers/net/Config.in - 1.66 linux/drivers/isdn/pcbit/pcbit.h - 1.9 linux/drivers/isdn/pcbit/layer2.c - 1.9 linux/drivers/isdn/pcbit/drv.c - 1.15 linux/drivers/isdn/hisax/netjet.c - 1.22 linux/drivers/isdn/hisax/isdnl1.c - 1.17 linux/drivers/isdn/hisax/isac.c - 1.14 linux/drivers/isdn/hisax/hscx.c - 1.13 linux/drivers/isdn/hisax/hisax.h - 1.30 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.16 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.16 linux/drivers/isdn/hisax/config.c - 1.31 linux/drivers/isdn/hisax/amd7930.c - 1.13 linux/drivers/isdn/hisax/Makefile - 1.22 linux/drivers/isdn/act2000/module.c - 1.11 linux/drivers/isdn/act2000/act2000.h - 1.8 linux/drivers/char/vt.c - 1.28 linux/drivers/char/tty_io.c - 1.55 linux/drivers/char/synclink.c - 1.27 linux/drivers/char/rocket_int.h - 1.4 linux/drivers/char/rocket.c - 1.19 linux/drivers/char/random.c - 1.32 linux/drivers/char/epca.c - 1.23 linux/drivers/char/cyclades.c - 1.23 linux/drivers/char/Makefile - 1.74 linux/drivers/char/Config.in - 1.67 linux/drivers/cdrom/sonycd535.c - 1.30 linux/drivers/cdrom/sjcd.c - 1.23 linux/drivers/cdrom/sbpcd.c - 1.30 linux/drivers/cdrom/optcd.c - 1.24 linux/drivers/cdrom/mcdx.c - 1.21 linux/drivers/cdrom/mcd.c - 1.24 linux/drivers/cdrom/gscd.c - 1.24 linux/drivers/cdrom/cm206.c - 1.25 linux/drivers/cdrom/cdu31a.c - 1.24 linux/drivers/cdrom/aztcd.c - 1.26 linux/drivers/block/z2ram.c - 1.20 linux/drivers/block/xd.c - 1.47 linux/drivers/block/swim3.c - 1.22 linux/drivers/block/rd.c - 1.62 linux/drivers/block/ps2esdi.c - 1.49 linux/drivers/block/paride/pseudo.h - 1.7 linux/drivers/block/paride/pf.c - 1.30 linux/drivers/block/paride/pd.c - 1.39 linux/drivers/block/paride/pcd.c - 1.26 linux/drivers/block/nbd.c - 1.45 linux/drivers/block/loop.c - 1.69 linux/drivers/block/ll_rw_blk.c - 1.117 linux/drivers/block/genhd.c - 1.36 linux/drivers/block/floppy.c - 1.53 linux/drivers/block/ataflop.c - 1.29 linux/drivers/block/amiflop.c - 1.30 linux/drivers/block/acsi.c - 1.39 linux/drivers/acorn/block/mfmhd.c - 1.32 linux/drivers/acorn/block/fd1772.c - 1.23 linux/arch/sparc64/mm/init.c - 1.51 linux/arch/sparc64/kernel/sys_sparc32.c - 1.59 linux/arch/sparc64/kernel/signal32.c - 1.28 linux/arch/sparc64/kernel/signal.c - 1.26 linux/arch/sparc64/defconfig - 1.79 linux/arch/sparc/mm/srmmu.c - 1.40 linux/arch/sparc/mm/generic.c - 1.12 linux/arch/sparc/mm/Makefile - 1.12 linux/arch/sparc/kernel/sun4d_irq.c - 1.17 linux/arch/sparc/kernel/sparc_ksyms.c - 1.31 linux/arch/sparc/kernel/signal.c - 1.29 linux/arch/sparc/boot/Makefile - 1.8 linux/arch/sparc/Makefile - 1.18 linux/arch/m68k/atari/stram.c - 1.20 linux/arch/i386/kernel/traps.c - 1.63 linux/arch/i386/kernel/mca.c - 1.15 linux/arch/i386/kernel/ioport.c - 1.6 linux/arch/i386/kernel/i386_ksyms.c - 1.58 linux/arch/i386/kernel/Makefile - 1.36 linux/arch/i386/config.in - 1.94 linux/arch/i386/boot/compressed/Makefile - 1.12 linux/arch/i386/boot/Makefile - 1.17 linux/arch/i386/Makefile - 1.33 linux/arch/alpha/lib/stxncpy.S - 1.5 linux/arch/alpha/lib/Makefile - 1.18 linux/arch/alpha/kernel/signal.c - 1.19 linux/arch/alpha/boot/Makefile - 1.12 linux/arch/alpha/Makefile - 1.22 linux/Rules.make - 1.32 linux/Makefile - 1.222 linux/MAINTAINERS - 1.120 linux/Documentation/Changes - 1.56 linux/CREDITS - 1.89 linux/include/linux/ide.h - 1.66 linux/fs/hpfs/super.c - 1.20 linux/fs/hpfs/namei.c - 1.18 linux/fs/hpfs/name.c - 1.3 linux/fs/hpfs/map.c - 1.4 linux/fs/hpfs/inode.c - 1.21 linux/fs/hpfs/hpfs_fn.h - 1.19 linux/fs/hpfs/dnode.c - 1.6 linux/fs/hpfs/dir.c - 1.16 linux/fs/hpfs/dentry.c - 1.3 linux/fs/hpfs/buffer.c - 1.12 linux/fs/hpfs/anode.c - 1.8 linux/fs/hpfs/alloc.c - 1.3 linux/drivers/isdn/hisax/isar.c - 1.19 linux/drivers/isdn/hisax/avm_pci.c - 1.16 linux/drivers/isdn/eicon/eicon_pci.h - 1.5 linux/drivers/isdn/eicon/eicon_pci.c - 1.10 linux/drivers/isdn/eicon/eicon_mod.c - 1.19 linux/drivers/isdn/eicon/eicon_isa.h - 1.8 linux/drivers/isdn/eicon/eicon_isa.c - 1.10 linux/drivers/isdn/eicon/eicon_io.c - 1.9 linux/drivers/isdn/eicon/eicon_idi.h - 1.7 linux/drivers/isdn/eicon/eicon_idi.c - 1.16 linux/drivers/isdn/eicon/eicon_dsp.h - 1.6 linux/drivers/isdn/eicon/eicon.h - 1.14 linux/arch/i386/vmlinux.lds.S - 1.9 linux/drivers/block/cpqarray.c - 1.58 linux/drivers/char/raw.c - 1.30 linux/drivers/char/sx.h - 1.5 linux/drivers/char/sx.c - 1.25 linux/include/linux/isapnp.h - 1.12 linux/drivers/scsi/oktagon_esp.c - 1.10 linux/drivers/pnp/isapnp.c - 1.30 linux/drivers/isdn/hisax/jade.c - 1.11 linux/drivers/isdn/hisax/hfc_pci.c - 1.25 linux/drivers/char/ip2main.c - 1.20 linux/drivers/char/ip2/i2lib.h - 1.6 linux/drivers/char/ip2/i2lib.c - 1.8 linux/drivers/char/ip2/i2ellis.h - 1.5 linux/drivers/atm/ambassador.h - 1.6 linux/drivers/atm/ambassador.c - 1.17 linux/drivers/block/DAC960.h - 1.19 linux/drivers/block/DAC960.c - 1.58 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.13 linux/net/irda/ircomm/ircomm_tty.c - 1.24 linux/net/irda/ircomm/ircomm_param.c - 1.12 linux/include/net/irda/ircomm_tty.h - 1.11 linux/include/asm-sh/unistd.h - 1.15 linux/drivers/pcmcia/tcic.c - 1.16 linux/drivers/pcmcia/rsrc_mgr.c - 1.15 linux/drivers/pcmcia/i82365.c - 1.26 linux/drivers/pcmcia/ds.c - 1.22 linux/drivers/pcmcia/cs_internal.h - 1.11 linux/drivers/pcmcia/cs.c - 1.31 linux/drivers/pcmcia/cistpl.c - 1.13 linux/drivers/pci/syscall.c - 1.4 linux/drivers/block/swim_iop.c - 1.17 linux/include/asm-sparc64/pci.h - 1.13 linux/drivers/char/drm/gamma_dma.c - 1.11 linux/drivers/char/drm/drmP.h - 1.20 linux/drivers/char/drm/drm.h - 1.12 linux/Documentation/filesystems/proc.txt - 1.11 linux/include/linux/pci_ids.h - 1.76 linux/drivers/net/wan/sdla_ppp.c - 1.19 linux/mm/highmem.c - 1.45 linux/fs/proc/proc_misc.c - 1.44 linux/drivers/isdn/hisax/w6692.c - 1.14 linux/drivers/pci/pci.ids - 1.53 linux/drivers/net/sk98lin/Makefile - 1.7 linux/include/linux/mmzone.h - 1.29 linux/drivers/net/aironet4500_core.c - 1.20 linux/drivers/net/aironet4500_card.c - 1.17 linux/drivers/net/aironet4500.h - 1.11 linux/kernel/timer.c - 1.32 linux/drivers/scsi/scsi_lib.c - 1.50 linux/drivers/i2c/Makefile - 1.8 linux/drivers/i2c/Config.in - 1.8 linux/drivers/sbus/char/jsflash.c - 1.24 linux/drivers/pcmcia/yenta.c - 1.33 linux/drivers/pcmcia/pci_socket.h - 1.7 linux/drivers/pcmcia/pci_socket.c - 1.12 linux/drivers/telephony/ixj.h - 1.8 linux/drivers/telephony/ixj.c - 1.23 linux/net/ipv4/inetpeer.c - 1.7 linux/drivers/ieee1394/raw1394.c - 1.20 linux/drivers/ieee1394/ieee1394_core.h - 1.14 linux/drivers/ieee1394/pcilynx.c - 1.23 linux/drivers/ieee1394/ieee1394_core.c - 1.23 linux/drivers/ieee1394/ohci1394.c - 1.24 linux/arch/i386/kernel/apic.c - 1.35 linux/drivers/char/moxa.c - 1.14 linux/drivers/char/mxser.c - 1.19 linux/drivers/scsi/scsi_scan.c - 1.30 linux/drivers/net/wan/sdla_chdlc.c - 1.19 linux/Documentation/DMA-mapping.txt - 1.16 linux/drivers/scsi/qla1280.h - 1.6 linux/drivers/scsi/qla1280.c - 1.19 linux/include/asm-ia64/unistd.h - 1.25 linux/drivers/scsi/sun3_NCR5380.c - 1.5 linux/drivers/isdn/hisax/hfc_sx.c - 1.14 linux/drivers/isdn/hysdn/hysdn_defs.h - 1.12 linux/drivers/isdn/hysdn/hysdn_net.c - 1.11 linux/drivers/isdn/hysdn/hysdn_sched.c - 1.10 linux/drivers/isdn/hysdn/boardergo.c - 1.15 linux/drivers/net/skfp/Makefile - 1.6 linux/net/bridge/br_stp.c - 1.5 linux/net/bridge/br_if.c - 1.7 linux/include/asm-mips64/unistd.h - 1.11 linux/drivers/char/epca.h - 1.3 linux/drivers/char/sh-sci.h - 1.9 linux/drivers/char/sh-sci.c - 1.19 linux/net/econet/af_econet.c - 1.14 linux/drivers/usb/serial/usb-serial.h - 1.24 linux/drivers/usb/serial/usb-serial.c - 1.5 linux/drivers/usb/serial/Makefile - 1.22 linux/drivers/ide/ide.c - 1.71 linux/drivers/ide/ide-probe.c - 1.41 linux/drivers/ide/ide-pnp.c - 1.11 linux/drivers/ide/ide-disk.c - 1.49 linux/drivers/ide/ide-cd.c - 1.49 linux/drivers/ide/Config.in - 1.34 linux/drivers/block/elevator.c - 1.24 linux/Documentation/DocBook/Makefile - 1.36 linux/include/linux/elevator.h - 1.14 linux/include/linux/compatmac.h - 1.4 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.18 linux/net/ipv4/netfilter/ip_nat_core.c - 1.15 linux/include/linux/nfs_xdr.h - 1.10 linux/drivers/video/sa1100fb.c - 1.17 linux/drivers/usb/serial/keyspan_pda.c - 1.31 linux/drivers/usb/serial/ftdi_sio.c - 1.42 linux/drivers/usb/serial/usbserial.c - 1.44 linux/drivers/usb/serial/whiteheat.c - 1.32 linux/drivers/usb/serial/visor.c - 1.42 linux/drivers/usb/serial/omninet.c - 1.30 linux/drivers/net/wan/lmc/lmc_proto.c - 1.5 linux/drivers/net/wan/lmc/lmc_main.c - 1.11 linux/include/linux/nfs_page.h - 1.9 linux/fs/partitions/ibm.c - 1.15 linux/drivers/usb/serial/digi_acceleport.c - 1.32 linux/arch/s390/kernel/process.c - 1.14 linux/include/asm-s390/unistd.h - 1.12 linux/arch/s390/config.in - 1.14 linux/arch/s390/defconfig - 1.14 linux/include/asm-s390/irq.h - 1.8 linux/include/asm-s390/lowcore.h - 1.8 linux/include/asm-s390/system.h - 1.9 linux/arch/s390/kernel/Makefile - 1.9 linux/include/asm-s390/hardirq.h - 1.6 linux/include/asm-s390/checksum.h - 1.5 linux/include/asm-s390/spinlock.h - 1.6 linux/include/asm-s390/softirq.h - 1.7 linux/include/asm-s390/smp.h - 1.6 linux/arch/s390/kernel/entry.S - 1.20 linux/arch/s390/kernel/head.S - 1.9 linux/drivers/s390/net/iucv.c - 1.11 linux/drivers/s390/misc/chandev.c - 1.11 linux/drivers/s390/char/hwc_rw.c - 1.7 linux/drivers/s390/char/hwc_tty.c - 1.7 linux/drivers/s390/char/hwc.h - 1.6 linux/drivers/s390/char/con3215.c - 1.9 linux/include/asm-s390/s390io.h - 1.5 linux/arch/s390/kernel/init_task.c - 1.6 linux/arch/s390/kernel/irq.c - 1.11 linux/drivers/s390/block/dasd_eckd.c - 1.10 linux/drivers/s390/block/dasd.c - 1.30 linux/drivers/s390/Makefile - 1.9 linux/arch/s390/vmlinux.lds - 1.8 linux/include/asm-s390/ptrace.h - 1.7 linux/include/asm-s390/processor.h - 1.11 linux/include/asm-s390/pgtable.h - 1.16 linux/include/asm-s390/bitops.h - 1.8 linux/drivers/s390/block/dasd_proc.c - 1.8 linux/include/asm-s390/param.h - 1.3 linux/arch/s390/kernel/time.c - 1.8 linux/include/asm-s390/pgalloc.h - 1.8 linux/arch/s390/kernel/traps.c - 1.12 linux/arch/s390/kernel/ptrace.c - 1.9 linux/arch/s390/kernel/s390fpu.c - 1.4 linux/arch/s390/kernel/setup.c - 1.10 linux/arch/s390/kernel/signal.c - 1.13 linux/arch/s390/kernel/smp.c - 1.16 linux/arch/s390/lib/checksum.c - 1.3 linux/arch/s390/mm/extable.c - 1.4 linux/arch/s390/lib/Makefile - 1.6 linux/arch/s390/mm/fault.c - 1.11 linux/kdb/Makefile - 1.14 linux/kdb/modules/Makefile - 1.15 linux/kernel/kallsyms.c - 1.14 linux/drivers/usb/storage/transport.c - 1.30 linux/drivers/char/drm/Config.in - 1.6 linux/drivers/usb/storage/Makefile - 1.11 linux/drivers/usb/serial/keyspan.c - 1.34 linux/fs/jffs/inode-v23.c - 1.32 linux/fs/jffs/intrep.c - 1.16 linux/drivers/acpi/Makefile - 1.20 linux/drivers/mtd/ftl.c - 1.26 linux/drivers/mtd/mtdblock.c - 1.24 linux/net/ipv4/tcp_minisocks.c - 1.16 linux/include/asm-sparc/highmem.h - 1.8 linux/drivers/net/natsemi.c - 1.24 linux/drivers/media/video/cpia_pp.c - 1.6 linux/Documentation/networking/tuntap.txt - 1.4 linux/drivers/media/radio/radio-sf16fmi.c - 1.14 linux/drivers/isdn/hysdn/hycapi.c - 1.12 linux/drivers/isdn/hisax/icc.c - 1.8 linux/drivers/isdn/eicon/linsys.c - 1.5 linux/drivers/isdn/eicon/linio.c - 1.6 linux/drivers/isdn/eicon/common.c - 1.9 linux/drivers/isdn/eicon/adapter.h - 1.4 linux/drivers/isdn/eicon/Divas_mod.c - 1.7 linux/arch/i386/kernel/bluesmoke.c - 1.26 linux/drivers/acpi/dispatcher/Makefile - 1.6 linux/drivers/acpi/events/Makefile - 1.6 linux/drivers/acpi/hardware/Makefile - 1.6 linux/drivers/acpi/namespace/Makefile - 1.6 linux/drivers/acpi/parser/Makefile - 1.6 linux/drivers/acpi/resources/Makefile - 1.6 linux/drivers/acpi/tables/Makefile - 1.6 linux/drivers/block/cciss.c - 1.45 linux/drivers/block/cciss.h - 1.15 linux/drivers/md/md.c - 1.59 linux/drivers/net/hamachi.c - 1.18 linux/kernel/context.c - 1.10 linux/include/asm-parisc/unistd.h - 1.5 linux/arch/alpha/lib/ev6-stxncpy.S - 1.3 linux/drivers/usb/serial/mct_u232.c - 1.25 linux/drivers/usb/serial/empeg.c - 1.30 linux/include/linux/shmem_fs.h - 1.9 linux/mm/shmem.c - 1.47 linux/Documentation/filesystems/xfs.txt - 1.13 linux/drivers/char/drm/radeon_drm.h - 1.7 linux/drivers/char/drm/radeon_drv.h - 1.9 linux/drivers/char/drm/radeon_state.c - 1.8 linux/fs/reiserfs/journal.c - 1.35 linux/include/linux/reiserfs_fs.h - 1.33 linux/include/linux/reiserfs_fs_sb.h - 1.16 linux/include/asm-s390/dasd.h - 1.8 linux/arch/s390x/kernel/traps.c - 1.8 linux/arch/s390x/kernel/time.c - 1.7 linux/include/asm-s390x/ptrace.h - 1.4 linux/arch/s390x/kernel/smp.c - 1.13 linux/include/asm-s390x/processor.h - 1.7 linux/arch/s390x/kernel/signal32.c - 1.8 linux/include/asm-s390x/pgtable.h - 1.12 linux/include/asm-s390x/pgalloc.h - 1.7 linux/include/asm-s390x/param.h - 1.3 linux/arch/s390x/kernel/signal.c - 1.10 linux/arch/s390x/kernel/setup.c - 1.9 linux/include/asm-s390x/lowcore.h - 1.6 linux/include/asm-s390x/irq.h - 1.7 linux/arch/s390x/kernel/s390fpu.c - 1.2 linux/include/asm-s390x/hardirq.h - 1.4 linux/include/asm-s390x/debug.h - 1.6 linux/include/asm-s390x/dasd.h - 1.9 linux/include/asm-s390x/checksum.h - 1.3 linux/include/asm-s390x/s390io.h - 1.4 linux/include/asm-s390x/bitops.h - 1.4 linux/arch/s390x/kernel/ptrace.c - 1.8 linux/arch/s390x/kernel/process.c - 1.11 linux/arch/s390x/kernel/linux32.h - 1.3 linux/arch/s390x/kernel/linux32.c - 1.15 linux/arch/s390x/kernel/irq.c - 1.8 linux/arch/s390x/kernel/init_task.c - 1.6 linux/arch/s390x/kernel/head.S - 1.8 linux/include/asm-s390x/setup.h - 1.5 linux/drivers/s390/s390mach.c - 1.7 linux/drivers/s390/net/netiucv.c - 1.11 linux/include/asm-s390x/smp.h - 1.5 linux/drivers/s390/net/ctcmain.c - 1.8 linux/arch/s390x/kernel/entry.S - 1.14 linux/arch/s390x/kernel/debug.c - 1.8 linux/arch/s390x/kernel/Makefile - 1.9 linux/arch/s390x/defconfig - 1.13 linux/arch/s390x/config.in - 1.9 linux/arch/s390x/mm/fault.c - 1.9 linux/include/asm-s390x/softirq.h - 1.6 linux/include/asm-s390x/spinlock.h - 1.6 linux/drivers/s390/block/xpram.c - 1.27 linux/include/asm-s390x/system.h - 1.7 linux/drivers/s390/block/dasd_fba.c - 1.8 linux/drivers/s390/block/dasd_diag.c - 1.8 linux/arch/s390x/lib/checksum.c - 1.2 linux/arch/s390x/lib/Makefile - 1.6 linux/arch/s390x/kernel/wrapper32.S - 1.7 linux/include/asm-cris/unistd.h - 1.9 linux/include/asm-s390x/unistd.h - 1.9 linux/drivers/pcmcia/hd64465_ss.c - 1.6 linux/include/asm-s390/debug.h - 1.6 linux/arch/s390/kernel/debug.c - 1.8 linux/arch/s390x/vmlinux.lds - 1.8 linux/arch/s390x/Makefile - 1.12 linux/drivers/scsi/aic7xxx_old.c - 1.21 linux/drivers/net/sungem.h - 1.8 linux/drivers/net/sungem.c - 1.21 linux/drivers/s390/char/ctrlchar.c - 1.4 linux/drivers/s390/char/ctrlchar.h - 1.3 linux/drivers/s390/char/tubfs.c - 1.6 linux/drivers/s390/char/tubio.h - 1.6 linux/drivers/s390/char/tubtty.c - 1.7 linux/net/wanrouter/af_wanpipe.c - 1.9 linux/drivers/s390/net/ctctty.c - 1.5 linux/arch/s390x/lib/misaligned.c - 1.2 linux/arch/s390/lib/misaligned.c - 1.2 linux/include/linux/if_wanpipe_common.h - 1.2 linux/drivers/net/wireless/orinoco.c - 1.12 linux/drivers/net/wireless/orinoco.h - 1.10 linux/include/net/bluetooth/bluetooth.h - 1.6 linux/include/net/bluetooth/hci.h - 1.5 linux/include/net/bluetooth/hci_core.h - 1.5 linux/drivers/bluetooth/hci_usb.c - 1.13 linux/drivers/bluetooth/Makefile - 1.6 linux/drivers/bluetooth/Config.in - 1.5 linux/net/bluetooth/Config.in - 1.3 linux/net/bluetooth/Makefile - 1.5 linux/net/bluetooth/af_bluetooth.c - 1.6 linux/net/bluetooth/hci_core.c - 1.8 linux/net/bluetooth/hci_sock.c - 1.7 linux/net/bluetooth/lib.c - 1.5 linux/drivers/mtd/nftlcore.c - 1.25 linux/drivers/mtd/mtdblock_ro.c - 1.14 linux/drivers/mtd/maps/Makefile - 1.4 linux/drivers/mtd/maps/Config.in - 1.7 linux/drivers/acpi/utilities/Makefile - 1.4 linux/drivers/net/wireless/airo.c - 1.22 linux/drivers/acpi/executer/Makefile - 1.4 linux/drivers/usb/serial/cyberjack.c - 1.19 linux/drivers/usb/serial/pl2303.c - 1.21 linux/drivers/isdn/tpam/tpam_queues.c - 1.3 linux/drivers/isdn/tpam/tpam_main.c - 1.7 linux/drivers/isdn/tpam/tpam.h - 1.5 linux/drivers/usb/usb-skeleton.c - 1.16 linux/drivers/message/fusion/mptscsih.h - 1.6 linux/drivers/message/fusion/mptscsih.c - 1.10 linux/drivers/message/fusion/mptlan.h - 1.4 linux/drivers/message/fusion/mptlan.c - 1.6 linux/drivers/message/fusion/Makefile - 1.9 linux/drivers/ieee1394/sbp2.c - 1.12 linux/drivers/ieee1394/nodemgr.c - 1.12 linux/Documentation/s390/CommonIO - 1.4 linux/drivers/s390/block/dasd_int.h - 1.8 linux/drivers/char/drm/radeon.h - 1.5 linux/drivers/char/drm/drm_drv.h - 1.9 linux/drivers/char/drm/drm_dma.h - 1.3 linux/drivers/char/drm/ati_pcigart.h - 1.6 linux/drivers/video/sa1100fb.h - 1.6 linux/arch/s390x/vmlinux-shared.lds - 1.6 linux/arch/s390/vmlinux-shared.lds - 1.6 linux/drivers/telephony/ixj_pcmcia.c - 1.2 linux/drivers/net/ns83820.c - 1.15 linux/fs/jffs2/background.c - 1.12 linux/include/linux/jffs2_fs_sb.h - 1.7 linux/drivers/usb/serial/ir-usb.c - 1.21 linux/drivers/pcmcia/sa1100_generic.c - 1.10 linux/drivers/message/i2o/i2o_lan.h - 1.2 linux/drivers/message/i2o/i2o_lan.c - 1.5 linux/drivers/message/i2o/i2o_block.c - 1.23 linux/drivers/pcmcia/i82092.c - 1.7 linux/net/ipv6/netfilter/ip6t_LOG.c - 1.3 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.5 linux/net/8021q/vlan_dev.c - 1.5 linux/net/8021q/vlan.c - 1.6 linux/drivers/atm/idt77252.h - 1.4 linux/drivers/atm/idt77252.c - 1.7 linux/drivers/scsi/sym53c8xx_2/Makefile - 1.5 linux/fs/ext3/inode.c - 1.23 linux/drivers/hotplug/cpqphp_proc.c - 1.5 linux/drivers/hotplug/cpqphp_pci.c - 1.6 linux/drivers/hotplug/cpqphp_nvram.c - 1.4 linux/drivers/hotplug/cpqphp_ctrl.c - 1.5 linux/drivers/hotplug/cpqphp_core.c - 1.8 linux/drivers/hotplug/cpqphp.h - 1.4 linux/include/linux/ext3_fs.h - 1.9 linux/fs/nfs/pagelist.c - 1.6 linux/init/do_mounts.c - 1.19 linux/mm/mempool.c - 1.12 linux/drivers/usb/serial/ipaq.c - 1.15 linux/drivers/usb/serial/kl5kusb105.c - 1.14 linux/drivers/ide/ide-taskfile.c - 1.22 linux/net/ipv4/tcp_diag.c - 1.5 linux/drivers/ieee1394/dv1394-private.h - 1.5 linux/drivers/ieee1394/dv1394.c - 1.8 linux/net/ipv6/netfilter/ip6_queue.c - 1.4 linux/arch/i386/Config.help - 1.15 linux/net/bluetooth/Config.help - 1.3 linux/arch/s390/Config.help - 1.3 linux/arch/s390x/Config.help - 1.3 linux/fs/Config.help - 1.20 linux/drivers/scsi/Config.help - 1.3 linux/drivers/bluetooth/Config.help - 1.4 linux/drivers/char/Config.help - 1.11 linux/drivers/i2c/Config.help - 1.2 linux/drivers/mtd/maps/Config.help - 1.2 linux/sound/synth/emux/soundfont.c - 1.3 linux/sound/synth/emux/emux_synth.c - 1.5 linux/sound/synth/emux/emux_seq.c - 1.3 linux/sound/synth/emux/emux_proc.c - 1.3 linux/sound/synth/emux/emux_oss.c - 1.3 linux/sound/synth/emux/emux_nrpn.c - 1.2 linux/sound/synth/emux/emux_effect.c - 1.4 linux/sound/sound_core.c - 1.5 linux/sound/ppc/tumbler.c - 1.5 linux/sound/ppc/powermac.c - 1.5 linux/sound/ppc/pmac.h - 1.3 linux/sound/ppc/pmac.c - 1.6 linux/sound/ppc/keywest.c - 1.5 linux/sound/ppc/daca.c - 1.4 linux/sound/ppc/burgundy.c - 1.4 linux/sound/ppc/awacs.c - 1.6 linux/sound/pci/ymfpci/ymfpci_main.c - 1.7 linux/sound/pci/ymfpci/ymfpci.c - 1.9 linux/sound/pci/via8233.c - 1.10 linux/sound/pci/via686.c - 1.9 linux/sound/pci/trident/trident_memory.c - 1.4 linux/sound/pci/trident/trident_main.c - 1.6 linux/sound/pci/trident/trident.c - 1.6 linux/sound/pci/sonicvibes.c - 1.7 linux/sound/pci/rme9652/rme9652.c - 1.10 linux/sound/pci/rme96.c - 1.9 linux/sound/pci/nm256/nm256.c - 1.9 linux/sound/pci/maestro3.c - 1.9 linux/sound/pci/korg1212/korg1212.c - 1.10 linux/sound/pci/intel8x0.c - 1.10 linux/sound/pci/ice1712.c - 1.10 linux/sound/pci/fm801.c - 1.7 linux/sound/pci/es1968.c - 1.9 linux/sound/pci/es1938.c - 1.7 linux/sound/pci/ens1370.c - 1.9 linux/sound/pci/emu10k1/voice.c - 1.3 linux/sound/pci/emu10k1/memory.c - 1.5 linux/sound/pci/emu10k1/irq.c - 1.3 linux/sound/pci/emu10k1/io.c - 1.3 linux/sound/pci/emu10k1/emuproc.c - 1.6 linux/sound/pci/emu10k1/emupcm.c - 1.7 linux/sound/pci/emu10k1/emumpu401.c - 1.5 linux/sound/pci/emu10k1/emumixer.c - 1.6 linux/sound/pci/emu10k1/emufx.c - 1.7 linux/sound/pci/emu10k1/emu10k1_patch.c - 1.2 linux/sound/pci/emu10k1/emu10k1_main.c - 1.6 linux/sound/pci/emu10k1/emu10k1_callback.c - 1.3 linux/sound/pci/emu10k1/emu10k1.c - 1.6 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.7 linux/sound/pci/cs4281.c - 1.10 linux/sound/pci/cmipci.c - 1.10 linux/sound/pci/als4000.c - 1.7 linux/sound/pci/ali5451/ali5451.c - 1.9 linux/sound/pci/ac97/ak4531_codec.c - 1.3 linux/sound/pci/ac97/ac97_codec.c - 1.8 linux/sound/pci/ac97/Makefile - 1.8 linux/sound/pci/Makefile - 1.7 linux/sound/pci/Config.in - 1.7 linux/sound/oss/maestro3.c - 1.4 linux/sound/isa/wavefront/wavefront_synth.c - 1.5 linux/sound/isa/wavefront/wavefront_midi.c - 1.4 linux/sound/isa/wavefront/wavefront_fx.c - 1.4 linux/sound/isa/wavefront/wavefront.c - 1.7 linux/sound/isa/sgalaxy.c - 1.6 linux/sound/isa/sb/sb_mixer.c - 1.4 linux/sound/isa/sb/sb_common.c - 1.7 linux/sound/isa/sb/sb8_midi.c - 1.3 linux/sound/isa/sb/sb8_main.c - 1.3 linux/sound/isa/sb/sb16_main.c - 1.5 linux/sound/isa/sb/sb16_csp.c - 1.5 linux/sound/isa/sb/es968.c - 1.6 linux/sound/isa/sb/emu8000_patch.c - 1.2 linux/sound/isa/sb/emu8000_callback.c - 1.3 linux/sound/isa/sb/emu8000.c - 1.6 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.6 linux/sound/isa/opl3sa2.c - 1.8 linux/sound/isa/gus/interwave.c - 1.7 linux/sound/isa/gus/gus_volume.c - 1.3 linux/sound/isa/gus/gus_uart.c - 1.3 linux/sound/isa/gus/gus_timer.c - 1.3 linux/sound/isa/gus/gus_simple.c - 1.3 linux/sound/isa/gus/gus_sample.c - 1.3 linux/sound/isa/gus/gus_reset.c - 1.3 linux/sound/isa/gus/gus_pcm.c - 1.5 linux/sound/isa/gus/gus_mixer.c - 1.3 linux/sound/isa/gus/gus_mem_proc.c - 1.4 linux/sound/isa/gus/gus_mem.c - 1.3 linux/sound/isa/gus/gus_main.c - 1.4 linux/sound/isa/gus/gus_lfo.c - 1.2 linux/sound/isa/gus/gus_irq.c - 1.2 linux/sound/isa/gus/gus_io.c - 1.3 linux/sound/isa/gus/gus_instr.c - 1.3 linux/sound/isa/gus/gus_dram.c - 1.3 linux/sound/isa/gus/gus_dma.c - 1.3 linux/sound/isa/es18xx.c - 1.7 linux/sound/isa/es1688/es1688_lib.c - 1.4 linux/sound/isa/cs423x/cs4236_lib.c - 1.3 linux/sound/isa/cs423x/cs4231_lib.c - 1.6 linux/sound/isa/cmi8330.c - 1.7 linux/sound/isa/ad1848/ad1848_lib.c - 1.7 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.5 linux/sound/i2c/tea6330t.c - 1.3 linux/sound/i2c/i2c.c - 1.4 linux/sound/i2c/cs8427.c - 1.4 linux/sound/drivers/serial-u16550.c - 1.8 linux/sound/drivers/opl3/opl3_synth.c - 1.2 linux/sound/drivers/opl3/opl3_seq.c - 1.4 linux/sound/drivers/opl3/opl3_oss.c - 1.3 linux/sound/drivers/opl3/opl3_midi.c - 1.2 linux/sound/drivers/opl3/opl3_lib.c - 1.5 linux/sound/drivers/opl3/opl3_drums.c - 1.2 linux/sound/drivers/mtpav.c - 1.6 linux/sound/drivers/mpu401/mpu401_uart.c - 1.7 linux/sound/drivers/mpu401/Makefile - 1.8 linux/sound/drivers/dummy.c - 1.7 linux/sound/core/wrappers.c - 1.2 linux/sound/core/timer.c - 1.6 linux/sound/core/sound_oss.c - 1.4 linux/sound/core/sound.c - 1.8 linux/sound/core/seq/seq_virmidi.c - 1.7 linux/sound/core/seq/seq_timer.c - 1.5 linux/sound/core/seq/seq_system.c - 1.2 linux/sound/core/seq/seq_queue.h - 1.8 linux/sound/core/seq/seq_queue.c - 1.8 linux/sound/core/seq/seq_prioq.c - 1.4 linux/sound/core/seq/seq_ports.c - 1.5 linux/sound/core/seq/seq_memory.c - 1.5 linux/sound/core/seq/seq_lock.c - 1.3 linux/sound/core/seq/seq_info.c - 1.2 linux/sound/core/seq/seq_fifo.c - 1.3 linux/sound/core/seq/seq_device.c - 1.5 linux/sound/core/seq/seq_clientmgr.h - 1.5 linux/sound/core/seq/seq_clientmgr.c - 1.8 linux/sound/core/seq/oss/seq_oss_writeq.c - 1.2 linux/sound/core/seq/oss/seq_oss_timer.c - 1.2 linux/sound/core/seq/oss/seq_oss_synth.c - 1.4 linux/sound/core/seq/oss/seq_oss_rw.c - 1.2 linux/sound/core/seq/oss/seq_oss_readq.c - 1.3 linux/sound/core/seq/oss/seq_oss_midi.c - 1.5 linux/sound/core/seq/oss/seq_oss_ioctl.c - 1.2 linux/sound/core/seq/oss/seq_oss_init.c - 1.4 linux/sound/core/seq/oss/seq_oss_event.c - 1.2 linux/sound/core/seq/oss/seq_oss.c - 1.4 linux/sound/core/seq/Makefile - 1.13 linux/sound/core/rtctimer.c - 1.11 linux/sound/core/rawmidi.c - 1.8 linux/sound/core/pcm_timer.c - 1.3 linux/sound/core/pcm_native.c - 1.8 linux/sound/core/pcm_misc.c - 1.4 linux/sound/core/pcm_memory.c - 1.4 linux/sound/core/pcm_lib.c - 1.7 linux/sound/core/pcm.c - 1.6 linux/sound/core/oss/route.c - 1.3 linux/sound/core/oss/rate.c - 1.3 linux/sound/core/oss/pcm_plugin.c - 1.4 linux/sound/core/oss/pcm_oss.c - 1.9 linux/sound/core/oss/mulaw.c - 1.3 linux/sound/core/oss/mixer_oss.c - 1.4 linux/sound/core/oss/linear.c - 1.3 linux/sound/core/oss/io.c - 1.4 linux/sound/core/oss/copy.c - 1.3 linux/sound/core/misc.c - 1.7 linux/sound/core/memory.c - 1.10 linux/sound/core/isadma.c - 1.3 linux/sound/core/init.c - 1.5 linux/sound/core/info_oss.c - 1.4 linux/sound/core/info.c - 1.7 linux/sound/core/hwdep.c - 1.4 linux/sound/core/device.c - 1.7 linux/sound/core/control.c - 1.6 linux/sound/core/Makefile - 1.13 linux/sound/Makefile - 1.11 linux/sound/Config.in - 1.5 linux/include/sound/version.h - 1.10 linux/include/sound/sndmagic.h - 1.5 linux/include/sound/snd_wavefront.h - 1.2 linux/include/sound/pcm.h - 1.6 linux/include/sound/opl3.h - 1.4 linux/include/sound/mpu401.h - 1.3 linux/include/sound/mixer_oss.h - 1.3 linux/include/sound/emu10k1.h - 1.7 linux/include/sound/cs46xx.h - 1.5 linux/include/sound/cs4231.h - 1.2 linux/include/sound/asound.h - 1.9 linux/include/sound/ad1848.h - 1.2 linux/include/sound/ac97_codec.h - 1.7 linux/include/asm-x86_64/unistd.h - 1.6 linux/include/asm-ppc64/unistd.h - 1.8 linux/drivers/net/e1000/e1000_main.c - 1.11 linux/drivers/net/e1000/e1000.h - 1.7 linux/fs/jfs/inode.c - 1.15 linux/fs/jfs/jfs_txnmgr.c - 1.18 linux/sound/pci/Config.help - 1.5 linux/sound/core/ioctl32/timer32.c - 1.4 linux/sound/core/ioctl32/rawmidi32.c - 1.4 linux/drivers/net/tulip/de4x5.c - 1.4 linux/sound/core/ioctl32/pcm32.c - 1.4 linux/sound/core/ioctl32/ioctl32.h - 1.3 linux/sound/core/ioctl32/ioctl32.c - 1.5 linux/sound/core/ioctl32/hwdep32.c - 1.3 linux/Documentation/sound/oss/Maestro3 - 1.2 linux/fs/jffs2/wbuf.c - 1.3 linux/kernel/futex.c - 1.10 linux/fs/jffs2/fs.c - 1.4 linux/sound/core/ioctl32/seq32.c - 1.3 linux/lib/radix-tree.c - 1.5 linux/drivers/usb/class/bluetty.c - 1.10 linux/drivers/usb/class/cdc-acm.c - 1.9 linux/drivers/usb/core/hub.c - 1.12 linux/drivers/usb/core/hub.h - 1.6 linux/drivers/usb/core/usb.c - 1.18 linux/drivers/usb/host/ehci-mem.c - 1.3 linux/drivers/usb/host/ohci-mem.c - 1.6 linux/drivers/ieee1394/amdtp.c - 1.4 linux/drivers/usb/input/usbkbd.c - 1.5 linux/drivers/ieee1394/eth1394.h - 1.2 linux/include/linux/radix-tree.h - 1.2 linux/drivers/usb/net/usbnet.c - 1.11 linux/drivers/usb/net/rtl8150.c - 1.8 linux/drivers/usb/net/pegasus.h - 1.7 linux/drivers/usb/misc/Config.help - 1.6 linux/drivers/usb/misc/Makefile - 1.5 linux/drivers/isdn/i4l/isdn_tty.c - 1.5 linux/drivers/isdn/i4l/isdn_ppp.h - 1.3 linux/drivers/isdn/i4l/isdn_ppp.c - 1.9 linux/drivers/isdn/i4l/isdn_net.h - 1.7 linux/drivers/isdn/i4l/isdn_net.c - 1.7 linux/drivers/isdn/i4l/isdn_concap.h - 1.3 linux/drivers/isdn/i4l/isdn_concap.c - 1.3 linux/drivers/isdn/i4l/isdn_common.h - 1.4 linux/drivers/isdn/i4l/isdn_common.c - 1.8 linux/drivers/isdn/i4l/Makefile - 1.5 linux/drivers/isdn/capi/kcapi.c - 1.4 linux/drivers/char/synclinkmp.c - 1.3 linux/sound/pci/rme32.c - 1.5 linux/drivers/char/pcmcia/synclink_cs.c - 1.3 linux/sound/arm/sa11xx-uda1341.c - 1.5 linux/sound/i2c/l3/uda1341.c - 1.2 linux/scripts/mkcompile_h - 1.7 linux/drivers/block/umem.c - 1.11 linux/drivers/usb/host/uhci-hcd.c - 1.9 linux/drivers/net/wan/pc300_tty.c - 1.2 linux/drivers/pci/pool.c - 1.6 linux/include/linux/page-flags.h - 1.13 linux/net/bluetooth/sco.c - 1.3 linux/net/bluetooth/l2cap.c - 1.3 linux/net/bluetooth/hci_event.c - 1.2 linux/net/bluetooth/hci_conn.c - 1.2 linux/drivers/bluetooth/hci_usb.h - 1.2 linux/drivers/bluetooth/hci_h4.c - 1.3 linux/drivers/bluetooth/hci_h4.h - 1.2 linux/drivers/bluetooth/hci_ldisc.c - 1.3 linux/mm/page-writeback.c - 1.13 linux/include/linux/buffer_head.h - 1.12 linux/drivers/bluetooth/hci_uart.h - 1.2 linux/kernel/suspend.c - 1.15 linux/Documentation/swsusp.txt - 1.3 linux/include/linux/suspend.h - 1.5 linux/fs/mpage.c - 1.10 linux/drivers/usb/core/message.c - 1.8 linux/drivers/acpi/osl.c - 1.6 linux/drivers/s390/cio/cio_debug.h - 1.2 linux/include/asm-s390/tlbflush.h - 1.2 linux/drivers/s390/cio/ioinfo.c - 1.2 linux/include/asm-s390x/rwsem.h - 1.2 linux/drivers/s390/cio/cio_debug.c - 1.2 linux/drivers/isdn/hisax/amd7930_fn.c - 1.4 linux/drivers/isdn/hisax/ipacx.c - 1.4 linux/drivers/s390/cio/blacklist.c - 1.2 linux/scripts/fixdep.c - 1.5 linux/include/asm-s390x/thread_info.h - 1.2 linux/drivers/s390/cio/airq.c - 1.2 linux/drivers/s390/cio/misc.c - 1.2 linux/drivers/s390/cio/Makefile - 1.3 linux/include/asm-s390x/tlbflush.h - 1.2 linux/drivers/s390/qdio.c - 1.3 linux/drivers/s390/net/lcs.c - 1.3 linux/drivers/s390/cio/chsc.c - 1.2 linux/drivers/s390/cio/proc.c - 1.2 linux/drivers/s390/cio/s390io.c - 1.3 linux/include/asm-s390/thread_info.h - 1.2 linux/include/asm-s390/rwsem.h - 1.2 linux/drivers/s390/cio/cio.c - 1.2 linux/drivers/s390/cio/chsc.h - 1.2 linux/drivers/s390/block/dasd_devmap.c - 1.2 linux/drivers/s390/block/dasd_genhd.c - 1.9 linux/drivers/s390/block/dasd_ioctl.c - 1.5 linux/drivers/s390/cio/requestirq.c - 1.2 linux/net/llc/llc_if.c - 1.6 linux/include/net/llc_main.h - 1.6 linux/net/llc/llc_sap.c - 1.7 linux/net/llc/llc_mac.c - 1.7 linux/include/net/llc_mac.h - 1.5 linux/net/llc/Makefile - 1.4 linux/net/llc/llc_pdu.c - 1.5 linux/net/llc/llc_c_ac.c - 1.7 linux/net/llc/llc_main.c - 1.8 linux/net/llc/llc_conn.c - 1.7 linux/include/net/llc_conn.h - 1.6 linux/sound/ppc/tumbler_volume.h - 1.2 linux/sound/pci/rme9652/hdsp.c - 1.3 linux/sound/pci/rme9652/hammerfall_mem.c - 1.2 linux/sound/isa/sb/emu8000_pcm.c - 1.2 linux/drivers/input/keyboard/atkbd.c - 1.6 linux/drivers/input/power.c - 1.3 linux/drivers/input/mouse/psmouse.c - 1.6 linux/drivers/input/joystick/iforce/Makefile - 1.3 linux/drivers/input/mouse/Config.help - 1.2 linux/drivers/input/keyboard/sunkbd.c - 1.5 linux/fs/direct-io.c - 1.9 linux/drivers/serial/amba.c - 1.3 linux/mm/rmap.c - 1.8 linux/drivers/serial/8250.h - 1.2 linux/drivers/serial/8250_cs.c - 1.2 linux/drivers/serial/8250.c - 1.6 linux/drivers/serial/21285.c - 1.3 linux/include/linux/serial_core.h - 1.4 linux/drivers/char/drm/drm_os_linux.h - 1.3 linux/drivers/serial/sunzilog.c - 1.3 linux/drivers/serial/sunsab.c - 1.2 linux/drivers/serial/sunsu.c - 1.4 linux/net/sched/sch_htb.c - 1.4 linux/drivers/usb/misc/Config.in - 1.3 linux/include/linux/pagevec.h - 1.4 linux/drivers/usb/core/buffer.c - 1.3 linux/drivers/usb/misc/speedtouch.c - 1.3 linux/fs/aio.c - 1.5 linux/drivers/char/genrtc.c - 1.2 linux/net/sctp/protocol.c - 1.4 linux/include/net/sctp/sctp.h - 1.3 linux/include/linux/sctp.h - 1.2 linux/net/sctp/debug.c - 1.3 linux/net/sctp/inqueue.c - 1.2 linux/net/sctp/outqueue.c - 1.4 linux/include/net/sctp/sm.h - 1.3 linux/net/sctp/sm_make_chunk.c - 1.4 linux/net/sctp/sm_sideeffect.c - 1.4 linux/net/sctp/sm_statefuns.c - 1.4 linux/include/net/sctp/structs.h - 1.4 linux/net/sctp/socket.c - 1.4 linux/drivers/ide/ppc/Makefile - 1.3 linux/drivers/ide/pci/via82cxxx.h - 1.3 linux/drivers/ide/pci/via82cxxx.c - 1.3 linux/drivers/ide/pci/trm290.h - 1.3 linux/drivers/ide/pci/trm290.c - 1.4 linux/drivers/ide/pci/slc90e66.h - 1.3 linux/drivers/ide/pci/slc90e66.c - 1.3 linux/drivers/ide/pci/sl82c105.h - 1.3 linux/drivers/ide/pci/sl82c105.c - 1.4 linux/drivers/ide/pci/sis5513.h - 1.3 linux/drivers/ide/pci/sis5513.c - 1.3 linux/drivers/ide/pci/siimage.h - 1.3 linux/drivers/ide/pci/siimage.c - 1.3 linux/drivers/ide/pci/serverworks.h - 1.3 linux/drivers/ide/pci/serverworks.c - 1.3 linux/drivers/ide/pci/rz1000.h - 1.3 linux/drivers/ide/pci/rz1000.c - 1.3 linux/drivers/ide/pci/piix.h - 1.3 linux/drivers/ide/pci/piix.c - 1.3 linux/drivers/ide/pci/pdcadma.h - 1.3 linux/drivers/ide/pci/pdcadma.c - 1.3 linux/drivers/ide/pci/pdc202xx_old.h - 1.3 linux/drivers/ide/pci/pdc202xx_old.c - 1.3 linux/drivers/ide/pci/pdc202xx_new.h - 1.3 linux/drivers/ide/pci/pdc202xx_new.c - 1.3 linux/drivers/ide/pci/opti621.h - 1.3 linux/drivers/ide/pci/opti621.c - 1.3 linux/drivers/ide/pci/nvidia.h - 1.3 linux/drivers/ide/pci/nvidia.c - 1.3 linux/drivers/ide/pci/ns87415.h - 1.3 linux/drivers/ide/pci/ns87415.c - 1.3 linux/drivers/ide/pci/it8172.h - 1.3 linux/drivers/ide/pci/it8172.c - 1.3 linux/drivers/ide/pci/hpt366.h - 1.3 linux/drivers/ide/pci/hpt366.c - 1.3 linux/drivers/ide/pci/hpt34x.h - 1.3 linux/drivers/ide/pci/hpt34x.c - 1.3 linux/drivers/ide/pci/generic.h - 1.3 linux/drivers/ide/pci/generic.c - 1.3 linux/drivers/ide/pci/cy82c693.h - 1.4 linux/drivers/ide/pci/cy82c693.c - 1.5 linux/drivers/ide/pci/cs5530.h - 1.3 linux/drivers/ide/pci/cs5530.c - 1.3 linux/drivers/ide/pci/cmd64x.h - 1.3 linux/drivers/ide/pci/cmd64x.c - 1.3 linux/include/asm-um/unistd.h - 1.2 linux/drivers/ide/pci/amd74xx.h - 1.3 linux/drivers/ide/pci/amd74xx.c - 1.3 linux/drivers/ide/pci/alim15x3.h - 1.3 linux/drivers/ide/pci/alim15x3.c - 1.3 linux/drivers/ide/pci/aec62xx.h - 1.3 linux/drivers/ide/pci/aec62xx.c - 1.3 linux/drivers/ide/pci/adma100.h - 1.2 linux/drivers/ide/pci/Makefile - 1.4 linux/drivers/ide/legacy/hd.c - 1.6 linux/drivers/ide/legacy/Makefile - 1.4 linux/arch/um/drivers/ubd_kern.c - 1.3 linux/drivers/ide/ide-iops.c - 1.2 linux/drivers/ide/arm/Makefile - 1.3 linux/arch/s390x/vmlinux.lds.S - 1.3 linux/arch/s390/vmlinux.lds.S - 1.3 linux/arch/i386/mm/hugetlbpage.c - 1.3 linux/drivers/char/drm/radeon_mem.c - 1.2 linux/drivers/char/drm/radeon_irq.c - 1.3 linux/drivers/block/deadline-iosched.c - 1.2 linux/drivers/base/hotplug.c - 1.3 linux/fs/smbfs/symlink.c - 1.2 linux/drivers/isdn/i4l/isdn_ciscohdlck.c - 1.2 linux/Documentation/vm/hugetlbpage.txt - 1.2 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.2 linux/sound/pci/cs46xx/dsp_spos.h - 1.2 linux/sound/pci/cs46xx/dsp_spos.c - 1.2 linux/sound/pci/cs46xx/cs46xx_lib.h - 1.2 linux/sound/pci/ac97/ac97_patch.h - 1.2 linux/sound/pci/ac97/ac97_patch.c - 1.2 linux/sound/pci/ac97/ac97_id.h - 1.2 linux/sound/isa/dt019x.c - 1.2 linux/sound/core/pcm_sgbuf.c - 1.2 linux/net/llc/af_llc.c - 1.2 linux/include/sound/pcm_sgbuf.h - 1.2 linux/include/sound/cs46xx_dsp_spos.h - 1.2 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 8 12:15:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 12:15:44 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98JFbtG011433 for ; Tue, 8 Oct 2002 12:15:38 -0700 Received: (qmail 12004 invoked by uid 1000); 8 Oct 2002 19:30:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Oct 2002 19:30:54 -0000 Date: Tue, 8 Oct 2002 22:30:54 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Steve Lord cc: Linux XFS List Subject: Re: dir hashes In-Reply-To: <1034091188.7497.28.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi Steve On 8 Oct 2002, Steve Lord wrote: > Performance issues on lookup, or on modifications to the dir? Yes we > do have hashing in directories, which means lookups do not need to > walk the whole dir. > Good to hear that. I was wondering only on "lookup" case. > Larger directories are more work to process, and XFS will slowdown > on creation and removal for large directories, the btree code is > to blame here. > > Steve I see. Im not a specialist and Ill be very glad if someone would give me a formula to compute the number of average comparations given the number of directory entries. "btree" is a binary tree ? whould that mean that looking up a N entries directory would trigger maximum log2(N) comparations ? Also I dont know much about XFS's internal layout, especially transaction storing on the log. I want to compute the size of a proper log, given the number of metadata modifications per second (and probably the number of block writes/reads thad HDD can do in a second). What are the operations XFS uses journal ? I know of inode modifications which include: atime/mtime/ctime, size, owner, group, perm. Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Tue Oct 8 14:41:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 14:41:46 -0700 (PDT) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98LfYtG025142 for ; Tue, 8 Oct 2002 14:41:40 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C1802FA71 for ; Tue, 8 Oct 2002 14:41:25 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 942412FA71 for ; Tue, 8 Oct 2002 14:41:22 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 406253438 for ; Tue, 8 Oct 2002 14:41:12 -0700 (PDT) Subject: Re: 1.2 PreRelease avaliable From: Florin Andrei To: linux-xfs In-Reply-To: <1033780525.2804.41.camel@funky> References: <1033780525.2804.41.camel@funky> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Oct 2002 14:41:12 -0700 Message-Id: <1034113272.12926.33.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-04 at 18:15, Russell Cattelan wrote: > ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/ > The installer iso is also available. I will install a system that looks > and feels similar to a RedHat (tm) 8.0 system. > This is probably going to be the only spin of the installer iso, > as the amount of effort is not trivial. You're saying that the final 1.2 release will be the only spin, not the 1.2pre, right? ;-) -- Florin Andrei If you wear a tinfoil hat nowadays, people will just think you're advertising for some Mel Gibson movie. From owner-linux-xfs@oss.sgi.com Tue Oct 8 15:06:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 15:06:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98M6WtG025837 for ; Tue, 8 Oct 2002 15:06:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA15283; Tue, 8 Oct 2002 17:06:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA26349; Tue, 8 Oct 2002 17:06:26 -0500 (CDT) Subject: Re: 1.2 PreRelease avaliable From: Eric Sandeen To: Florin Andrei Cc: linux-xfs In-Reply-To: <1034113272.12926.33.camel@stantz.corp.sgi.com> References: <1033780525.2804.41.camel@funky> <1034113272.12926.33.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 08 Oct 2002 17:04:14 -0500 Message-Id: <1034114654.19293.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-10-08 at 16:41, Florin Andrei wrote: > On Fri, 2002-10-04 at 18:15, Russell Cattelan wrote: > > ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/ > > The installer iso is also available. I will install a system that looks > > and feels similar to a RedHat (tm) 8.0 system. > > This is probably going to be the only spin of the installer iso, > > as the amount of effort is not trivial. > > You're saying that the final 1.2 release will be the only spin, not the > 1.2pre, right? ;-) We'll see. Even if the 1.2pre is the only version we release, it's not that horrible if you have to do a kernel upgrade to get to 1.2-final. Installers are no fun, and the time can be better spent tracking down bugs. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Oct 8 20:17:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Oct 2002 20:17:15 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g993HDtG029409 for ; Tue, 8 Oct 2002 20:17:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA00342 for ; Tue, 8 Oct 2002 20:17:11 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA99158 for linux-xfs@oss.sgi.com; Wed, 9 Oct 2002 13:15:53 +1000 (EST) Date: Wed, 9 Oct 2002 13:15:53 +1000 (EST) From: Nathan Scott Message-Id: <200210090315.NAA99158@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - remove bcopy X-archive-position: 885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Global search and replace of the b* memory routines to their mem* equivalents. (bcopy->memcopy, ovbcopy->memmove, bzero->memset, bcmp->memcmp). Date: Tue Oct 8 20:04:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129465a linux/fs/xfs/dmapi/dmapi_event.c - 1.9 linux/fs/xfs/dmapi/dmapi_register.c - 1.19 linux/fs/xfs/dmapi/dmapi_right.c - 1.14 linux/fs/xfs/dmapi/dmapi_session.c - 1.13 Date: Tue Oct 8 20:06:48 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129466a linux/fs/xfs/xfs_log.c - 1.255 linux/fs/xfs/xfs_ialloc.c - 1.159 linux/fs/xfs/xfs_buf_item.c - 1.128 linux/fs/xfs/xfs_trans_inode.c - 1.39 linux/fs/xfs/xfs_da_btree.c - 1.134 linux/fs/xfs/xfs_vnodeops.c - 1.567 linux/fs/xfs/xfs_dir2_block.c - 1.26 linux/fs/xfs/xfs_attr_fetch.c - 1.12 linux/fs/xfs/xfs_dir.c - 1.142 linux/fs/xfs/xfs_rtalloc.c - 1.79 linux/fs/xfs/xfs_itable.c - 1.111 linux/fs/xfs/xfs_ialloc_btree.c - 1.68 linux/fs/xfs/xfs_dmapi.c - 1.81 linux/fs/xfs/xfs_inode_item.c - 1.104 linux/fs/xfs/xfs_qm_syscalls.c - 1.68 linux/fs/xfs/xfs_log_recover.c - 1.245 linux/fs/xfs/xfs_bmap_btree.c - 1.126 linux/fs/xfs/xfs_dir2_sf.h - 1.14 linux/fs/xfs/xfs_dir2_sf.c - 1.31 linux/fs/xfs/xfs_dquot.c - 1.70 linux/fs/xfs/xfs_dir_leaf.c - 1.104 linux/fs/xfs/xfs_mount.c - 1.304 linux/fs/xfs/xfs_qm.c - 1.87 linux/fs/xfs/xfs_dir2_data.c - 1.19 linux/fs/xfs/xfs_inode.c - 1.353 linux/fs/xfs/xfs_dir2_trace.c - 1.13 linux/fs/xfs/xfs_dir2_leaf.c - 1.28 linux/fs/xfs/xfs_attr_leaf.c - 1.64 linux/fs/xfs/xfs_error.c - 1.34 linux/fs/xfs/xfs_utils.c - 1.54 linux/fs/xfs/xfs_dir_sf.h - 1.21 linux/fs/xfs/xfs_fsops.c - 1.86 linux/fs/xfs/xfs_bmap.c - 1.293 linux/fs/xfs/xfs_alloc_btree.c - 1.71 linux/fs/xfs/xfs_trans_buf.c - 1.104 linux/fs/xfs/xfs_dir2_node.c - 1.27 linux/fs/xfs/xfs_attr.c - 1.97 linux/fs/xfs/xfs_dir2.c - 1.39 linux/fs/xfs/linux/xfs_iops.c - 1.178 linux/fs/xfs/xfs_arch.h - 1.36 linux/fs/xfs/linux/xfs_ioctl.c - 1.78 linux/fs/xfs/support/uuid.c - 1.9 linux/fs/xfs/support/move.h - 1.10 linux/fs/xfs/support/move.c - 1.9 linux/fs/xfs/xfs_fs.h - 1.4 From owner-linux-xfs@oss.sgi.com Wed Oct 9 03:32:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 03:32:45 -0700 (PDT) Received: from msrv.minfin.govrn.bg ([212.122.164.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99AWXtG005948 for ; Wed, 9 Oct 2002 03:32:37 -0700 Received: from fw124 ([192.168.32.1]) by msrv.minfin.govrn.bg (Netscape Messaging Server 3.62) with SMTP id 5444 for ; Wed, 9 Oct 2002 13:17:31 +0300 Reply-To: From: "Kostadin Karaivanov" To: Subject: Is this a expected behavior Date: Wed, 9 Oct 2002 13:19:56 +0300 Message-ID: <001501c26f7d$6b619e70$1504a8c0@larry2> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-archive-position: 886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.government.bg Precedence: bulk X-list: linux-xfs The system : root@larry:/usr/src# cat linux/fs/xfs/linux/xfs_version.h | grep \# #ifndef __XFS_VERSION_H__ #define __XFS_VERSION_H__ #define XFS_VERSION_STRING "CVS-10/09/02:05" #endif /* __XFS_VERSION_H__ */ / is on XFS partittion The problem (?): I have /usr/src directory like that root@larry:/usr/src# ls -al total 5752 drwxr-xr-x 8 root root 4096 ??? 9 12:55 ./ drwxr-xr-x 18 root root 4096 ??? 30 05:54 ../ drwxr-xr-x 8 79 304 4096 ??? 9 12:18 freeswan-2.00pre2/ -rw-r--r-- 1 root root 1707055 ??? 19 23:05 freeswan-2.00pre2.k2.0.patch -rw-r--r-- 1 root root 1707113 ??? 19 23:05 freeswan-2.00pre2.k2.2.patch -rw-r--r-- 1 root root 1706937 ??? 19 23:05 freeswan-2.00pre2.k2.4.patch lrwxr-xr-x 1 root root 19 ??? 9 12:22 linux -> linux-2.4-xfs/linux/ drwxr-xr-x 17 root root 4096 ??? 24 12:50 linux09152002+crypt/ drwxr-xr-x 5 root root 38 ??? 5 14:07 linux-2.4-xfs/ -rw-r--r-- 1 root root 29859 ??? 30 16:49 loop-jari-2.4.18.0.patch -rw-r--r-- 1 root root 678738 ??? 9 07:38 patch-int-2.4.19.1 drwxr-xr-x 2 root bin 20480 ??? 27 00:12 qmail-1.03/ drwxr-xr-x 7 root root 67 ??? 24 2002 rpm/ drwxr-xr-x 3 root root 83 ??? 22 19:33 test/ when I make root@larry:/usr/src# cd linux root@larry:/usr/src/linux# ls ../ cmd/ CVS/ linux/ I get the content of /usr/src/linux-2.4-xfs/ - although I have no memories about the behavior of privios kernels, I expect to get content of /usr/src itself cause when I make cd ../ I go to /usr/src..... is this expected ??? Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 larry@minfin.government.bg From owner-linux-xfs@oss.sgi.com Wed Oct 9 04:15:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 04:15:57 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99BFotG007063 for ; Wed, 9 Oct 2002 04:15:50 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 41A6DML7; Wed, 9 Oct 2002 07:15:50 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g99BFnk35313; Wed, 9 Oct 2002 07:15:49 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3DA40FE5.1040106@wgate.com> Date: Wed, 09 Oct 2002 07:15:49 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: larry@minfin.government.bg CC: linux-xfs@oss.sgi.com Subject: Re: Is this a expected behavior References: <001501c26f7d$6b619e70$1504a8c0@larry2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Kostadin Karaivanov wrote: > The system : > root@larry:/usr/src# cat linux/fs/xfs/linux/xfs_version.h | grep \# > #ifndef __XFS_VERSION_H__ > #define __XFS_VERSION_H__ > #define XFS_VERSION_STRING "CVS-10/09/02:05" > #endif /* __XFS_VERSION_H__ */ > > / is on XFS partittion > > The problem (?): I have /usr/src directory like that > root@larry:/usr/src# ls -al > total 5752 > drwxr-xr-x 8 root root 4096 ??? 9 12:55 ./ > drwxr-xr-x 18 root root 4096 ??? 30 05:54 ../ > drwxr-xr-x 8 79 304 4096 ??? 9 12:18 freeswan-2.00pre2/ > -rw-r--r-- 1 root root 1707055 ??? 19 23:05 > freeswan-2.00pre2.k2.0.patch > -rw-r--r-- 1 root root 1707113 ??? 19 23:05 > freeswan-2.00pre2.k2.2.patch > -rw-r--r-- 1 root root 1706937 ??? 19 23:05 > freeswan-2.00pre2.k2.4.patch > lrwxr-xr-x 1 root root 19 ??? 9 12:22 linux -> > linux-2.4-xfs/linux/ > drwxr-xr-x 17 root root 4096 ??? 24 12:50 > linux09152002+crypt/ > drwxr-xr-x 5 root root 38 ??? 5 14:07 linux-2.4-xfs/ > -rw-r--r-- 1 root root 29859 ??? 30 16:49 > loop-jari-2.4.18.0.patch > -rw-r--r-- 1 root root 678738 ??? 9 07:38 patch-int-2.4.19.1 > drwxr-xr-x 2 root bin 20480 ??? 27 00:12 qmail-1.03/ > drwxr-xr-x 7 root root 67 ??? 24 2002 rpm/ > drwxr-xr-x 3 root root 83 ??? 22 19:33 test/ > > when I make > root@larry:/usr/src# cd linux > root@larry:/usr/src/linux# ls ../ > cmd/ CVS/ linux/ > I get the content of /usr/src/linux-2.4-xfs/ - although I have no memories > about the behavior of privios kernels, I expect to get content of /usr/src > itself > cause when I make cd ../ I go to /usr/src..... is this expected ??? This is expected - the CWD is what the command (ls) runs in and the ".." points to the directory above. Some shells have, either as an option or default behavior, the feature that the "cd" command (which runs within the shell) interprets the string based on what path the shell thinks you went down. For example, in my system I have: farmer:/home/mks> ls -l linux lrwxrwxr-x 1 22 Mar 5 2002 linux -> /usr/src/linux-2.4-xfs/ so if I cd to linux, I get: farmer:/home/mks> cd linux farmer:/home/mks/linux> pwd /usr/src/linux-2.4-xfs The shell itself does the CD command and if I "cd .." I get: farmer:/home/mks/linux> cd .. farmer:/home/mks> However, that is only because the shell has its own concept of the current directory (as seen in the prompt) vs the actual/physical current directory (as seen by pwd) Unless the shell replaces the string "../" with something else, any external command (ls, cp, etc) will see that string within the context of the actual directory. This has, as far as I know, always been the case in Linux, Unix, etc. (Albeit, not all shells support the special handling and will end up just using the actual directory rather than the "logical" one.) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Wed Oct 9 04:32:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 04:33:04 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99BWwtG007625 for ; Wed, 9 Oct 2002 04:32:59 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g99BWuVg017220; Wed, 9 Oct 2002 13:32:57 +0200 (CEST) Message-Id: <4.3.2.7.2.20021009132330.02c35ff8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 13:31:13 +0200 To: Eric Sandeen , Florin Andrei From: Seth Mos Subject: Re: 1.2 PreRelease avaliable Cc: linux-xfs In-Reply-To: <1034114654.19293.12.camel@stout.americas.sgi.com> References: <1034113272.12926.33.camel@stantz.corp.sgi.com> <1033780525.2804.41.camel@funky> <1034113272.12926.33.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 17:04 8-10-2002 -0500, Eric Sandeen wrote: >On Tue, 2002-10-08 at 16:41, Florin Andrei wrote: > > On Fri, 2002-10-04 at 18:15, Russell Cattelan wrote: > > > ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/ > > > The installer iso is also available. I will install a system that looks > > > and feels similar to a RedHat (tm) 8.0 system. > > > This is probably going to be the only spin of the installer iso, > > > as the amount of effort is not trivial. > > > > You're saying that the final 1.2 release will be the only spin, not the > > 1.2pre, right? ;-) > >We'll see. Even if the 1.2pre is the only version we release, it's not >that horrible if you have to do a kernel upgrade to get to 1.2-final. The only problem I have with the installer as it is now is the text mode install which barfs before I even get to any install screen. I have not saved the dump yet though. I can reproduce it. The standard 8.0 text mode works though. I'll send it later. The first build I made with the 1.2pre1 kernel-source rpm on a 7.2 box hanged at bootup with "Uniform Multi-Platform E-IDE driver Revision: 6.31" And sometimes one line later. I will recompile this kernel from scratch and try again though. I don't think it is XFS related anyways. >Installers are no fun, and the time can be better spent tracking down >bugs. The only X installs is a bit of problem on my notebook though since the installers (redhat and sgi) contain a bug that incorrectly sets the size of installer screen on my notebook. Plus I have a few servers which don't have a mouse or a decent monitor which means I can't do a X install. Aargh... Just a request :-) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Oct 9 10:56:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 10:56:55 -0700 (PDT) Received: from mailcity.com (fes4-mail.whowhere.com [209.202.220.170] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99HuptG004441 for ; Wed, 9 Oct 2002 10:56:52 -0700 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed, 09 Oct 2002 17:56:33 -0000 To: amugojohn@lycos.com Date: Wed, 09 Oct 2002 19:56:33 +0200 From: "john hawagu" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: amugojohn@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 Subject: BUSINESS ASSISTANCE X-Sender-Ip: 212.87.127.249 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit X-archive-position: 890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: amugojohn@lycos.com Precedence: bulk X-list: linux-xfs CONFIDENCIAL FROM;MR.JOHN AMUGO HAWAGU E-MAIL:amugojohn@lycos.com REF:TRANSACTION REQEST I am aware that it is amazing when a business proposal letter come from someone that you do know, however, my name is Mr.John Amugo Hawagu. The purpose of my introduction is that I am the first son of DR.AMUGO HAWAGU,who was recently murdered in the land dispute in zimbabwe. Before the death of my father,he had taken me to amsterdam to deposit the sum of Eight Million, Five Hundred Thusand United states dollers (US8.5)in a security company,as if he forsaw the looming danger in Zimbabwe.The money was deposited in a box as gemstones to aviod much demurrage from the security company.this amount was meant for the purchase of new machines and chemicals for the farms and establishment of new farms in swaziland. This land problem came when zimbabwe president Mr.Robert Mugabe, introduced a new land act that wholly affected rich farmers and some few black farmers.this resulted to killing and mob action by zimbabwe war veterans and some lunatis in the society. infact,a lot of people wrere killed because of this land reformed act of which my father was one of the victims. It is against the background that my family and I who are currently staying in amsterdam decide to transfer my father money to a foreign account.since the law of the nederlands prohibit a refugee(assylum seeker)to open any account or to be involved in any financial transaction.as the eldest son of my father,I am saddled with the responsibility of seeking a genuine foreign account were this money could be transferred without the knowledge of my governmentwho are bent on taking everythings we have got,I am faced with the dilema of investing this amount of money in the nederlands for the fear of going through the same experience in future since both contries have similar history.moreover,the nederland foreign exchange policy does not allow such investment from assylum seekers. As a businessman,whom I have entrusted my future and my family in his hand,I must let you know that this transaction is risk free.if you accept to assist me and my family,all I need you to do for me is to make arrangement and come to amsterdam,the Nederland to meet with security company at their affliate office here in amsterdam, and for you to open non-resident account which will aid us in transfering the money in to any account you will nominate overseas.I have already given directives for the consignment to be brought to amsterdam. This money I intend to use for investment. I have options to offer you,first you can choose to have certain percentage of the money for nominating your account for the transaction,or you can go to parnership with me for a proper profitable investment of the money in your country.which ever option you choose,feel free to notify me.I have mapped out(5%percent)of this money for all expenses incurred in processing this transaction.if you do not prefer a partnership,I am willing to give you(15%percent)of the money while the remaining(80%percent)that is meant for me,will be for the investment in your country. please feel free to contact with the above addres: Thanks Yours Faithfully Mr John Amugo Hawagu ____________________________________________________________ Watch a championship game with Elway or McGwire. Enter Now at http://champions.lycos.com From owner-linux-xfs@oss.sgi.com Wed Oct 9 10:56:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 10:56:31 -0700 (PDT) Received: from mm-outgoing-101.amazon.com (mm-outgoing-101.amazon.com [207.171.188.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99HuQtG004395 for ; Wed, 9 Oct 2002 10:56:28 -0700 Received: from mail-ems-102.amazon.com by mm-outgoing-101.amazon.com with ESMTP (crosscheck: mail-ems-102.amazon.com [10.16.42.229]) id KAA-21335150-16130; Wed, 9 Oct 2002 10:19:15 -0700 Received: by mail-ems-102.amazon.com id AAA-21335150-25209,3530; 9 Oct 2002 19:18:31 +0200 Date: 9 Oct 2002 19:18:31 +0200 Message-ID: <.AAA-21335150-25209,3530.1034183911@mail-ems-102.amazon.com> X-AMAZON-TRACK: 21335150 To: linux-xfs@oss.sgi.com From: "Ok2mail.com" Subject: Offerts : 7 euros sur Amazon.fr ! Bounces-to: ems+TRN42AWYUVMZJW@bounces.amazon.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1202 X-archive-position: 889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: amazon_reply@ok2mail.com.sgi.com Precedence: bulk X-list: linux-xfs Faites-vous plaisir! Ok2mail.com vous offre un cheque-cadeau de 7 euros, a depenser illico sur Amazon.fr!!! Valable sur tout le catalogue Amazon.fr: Livres, Musique, DVD, Video, Logiciels, Jeux Video. Uniquement jusqu'au dimanche 27 octobre 2002. Profitez-en vite! Pour cela, notez bien votre code de cheque-cadeau: CA64-PE3HJF-4VNXEB Vous entrerez ce code sur la page de paiement, dans la case reservee a cet effet. Cliquez ici pour en profiter: http://www.amazon.fr/exec/obidos/redirect?tag=gcbuon2-21&path=tg/browse/-/405320 -------------------------------------------------------------------------- Votre cheque-cadeau est soumis aux conditions d'utilisation a consulter sur la page http://www.ok2mail.com/conditions_amazon.htm Important: ces cheques-cadeaux sont limites a 1 par foyer fiscal et par adresse de livraison, a utiliser avant le 27 octobre 2002. La livraison est gratuite a partir de 20 euros d'achats en mode rapide en France metropolitaine. Vous recevez cet e-mail de la part de Ok2mail.com. Si vous ne souhaitez plus recevoir d'offres speciales de notre part, rendez-vous sur: http://www.ok2mail.com/amazon/desinscription.htm [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Oct 9 13:05:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 13:05:48 -0700 (PDT) Received: from webcube3.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99K5itG010301 for ; Wed, 9 Oct 2002 13:05:44 -0700 Received: from there (host208-32-153-216.net-serv.com [216.153.32.208] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with SMTP id g99K5hi25699 for ; Wed, 9 Oct 2002 16:05:43 -0400 Message-Id: <200210092005.g99K5hi25699@webcube3.volstate.net> Content-Type: text/plain; charset="iso-8859-15" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Powered by XFS logo Date: Wed, 9 Oct 2002 14:41:25 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Is there some place that the Powered by XFS image file (that is in the RedHat 7.3 installer) is available for download? I would like to make a miniture and put it on my website (hopefully coming in a few weeks). Thanks; Joe From owner-linux-xfs@oss.sgi.com Wed Oct 9 23:33:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Oct 2002 23:33:17 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A6XFtG024920 for ; Wed, 9 Oct 2002 23:33:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 XAA07683 for ; Wed, 9 Oct 2002 23:33:13 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA15828 for linux-xfs@oss.sgi.com; Thu, 10 Oct 2002 16:31:56 +1000 (EST) Date: Thu, 10 Oct 2002 16:31:56 +1000 (EST) From: Nathan Scott Message-Id: <200210100631.QAA15828@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix libxfs buglet X-archive-position: 892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix libxfs device flush ioctl; sync with kernel source. CONTRIBUTED: Anton Blanchard Date: Wed Oct 9 23:29:03 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:129601a cmd/xfsprogs/VERSION - 1.60 cmd/xfsprogs/doc/CHANGES - 1.85 cmd/xfsprogs/debian/changelog - 1.53 - Bump version - fix libxfs device flush ioctl, sync with kernel source. cmd/xfsprogs/libxfs/init.c - 1.21 - libxfs was trying to do an fsync and BLKFLSBUF ioctl on a bogus file descriptor. CONTRIBUTED: Anton Blanchard cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.16 cmd/xfsprogs/include/xfs_fs.h - 1.21 cmd/xfsprogs/include/xfs_arch.h - 1.8 cmd/xfsprogs/include/xfs_dir2_sf.h - 1.7 cmd/xfsprogs/include/xfs_mount.h - 1.29 cmd/xfsprogs/include/xfs_inode.h - 1.26 cmd/xfsprogs/include/xfs_types.h - 1.14 cmd/xfsprogs/include/xfs_dir_sf.h - 1.7 cmd/xfsprogs/include/platform_defs.h.in - 1.11 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.15 cmd/xfsprogs/libxfs/rdwr.c - 1.12 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.18 cmd/xfsprogs/libxfs/xfs.h - 1.24 cmd/xfsprogs/libxfs/xfs_dir2_block.c - 1.9 cmd/xfsprogs/libxfs/xfs_dir.c - 1.10 cmd/xfsprogs/libxfs/xfs_ialloc_btree.c - 1.7 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.12 cmd/xfsprogs/libxfs/xfs_dir2_sf.c - 1.10 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.10 cmd/xfsprogs/libxfs/xfs_mount.c - 1.12 cmd/xfsprogs/libxfs/xfs_dir2_data.c - 1.8 cmd/xfsprogs/libxfs/xfs_inode.c - 1.14 cmd/xfsprogs/libxfs/xfs_dir2_leaf.c - 1.8 cmd/xfsprogs/libxfs/xfs_attr_leaf.c - 1.7 cmd/xfsprogs/libxfs/util.c - 1.10 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.16 cmd/xfsprogs/libxfs/xfs_alloc_btree.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.11 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.10 - Sync with kernel source (replace b* with mem* memory APIs). From owner-linux-xfs@oss.sgi.com Thu Oct 10 03:21:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 03:21:36 -0700 (PDT) Received: from c104 ([61.60.106.79]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AALPtG011097 for ; Thu, 10 Oct 2002 03:21:28 -0700 Date: Thu, 10 Oct 2002 03:21:25 -0700 Received: from seed by microsoft.com with SMTP id FKaEWQ0muUIaUYlxrrk1VRMPIk5z; Thu, 10 Oct 2002 18:21:19 +0800 Message-ID: From: vivian@kimo.com.tw To: 10081@oss.sgi.com, 10091@oss.sgi.com Subject: good job for you MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_OwchHPSJbabVvz5i91uMWBP" X-Mailer: MIJFh6s8ZKLexfppr3AIVYWdDjL X-Priority: 3 X-MSMail-Priority: Normal X-archive-position: 893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vivian@kimo.com.tw Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------=_NextPart_OwchHPSJbabVvz5i91uMWBP Content-Type: multipart/alternative; boundary="----=_NextPart_OwchHPSJbabVvz5i91uMWBPAA" ------=_NextPart_OwchHPSJbabVvz5i91uMWBPAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi DQp4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpv ZmZpY2UiDQp4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1U eXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1CaWc1Ij4NCjxtZXRh IG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5h bWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDkiPg0KPG1l dGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDki Pg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSIuLzKvwaj6p0u2T6q6s9C3 fqX6utAuZmlsZXMvZmlsZWxpc3QueG1sIj4NCjxsaW5rIHJlbD1FZGl0LVRp bWUtRGF0YSBocmVmPSIuLzKvwaj6p0u2T6q6s9C3fqX6utAuZmlsZXMvZWRp dGRhdGEubXNvIj4NCjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpEb2N1bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj5B QUE8L286QXV0aG9yPg0KICA8bzpUZW1wbGF0ZT5Ob3JtYWw8L286VGVtcGxh dGU+DQogIDxvOkxhc3RBdXRob3I+QUFBPC9vOkxhc3RBdXRob3I+DQogIDxv OlJldmlzaW9uPjEwPC9vOlJldmlzaW9uPg0KICA8bzpUb3RhbFRpbWU+NTwv bzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAwMi0wMy0wOFQxOToyMDow MFo8L286Q3JlYXRlZD4NCiAgPG86TGFzdFNhdmVkPjIwMDItMDctMTJUMTA6 MDE6MDBaPC9vOkxhc3RTYXZlZD4NCiAgPG86UGFnZXM+MTwvbzpQYWdlcz4N CiAgPG86V29yZHM+MTU4PC9vOldvcmRzPg0KICA8bzpDaGFyYWN0ZXJzPjkw NjwvbzpDaGFyYWN0ZXJzPg0KICA8bzpMaW5lcz43PC9vOkxpbmVzPg0KICA8 bzpQYXJhZ3JhcGhzPjE8L286UGFyYWdyYXBocz4NCiAgPG86Q2hhcmFjdGVy c1dpdGhTcGFjZXM+MTExMjwvbzpDaGFyYWN0ZXJzV2l0aFNwYWNlcz4NCiAg PG86VmVyc2lvbj45LjI4MTI8L286VmVyc2lvbj4NCiA8L286RG9jdW1lbnRQ cm9wZXJ0aWVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpDb21wYXRpYmls aXR5Pg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0 eT4NCiA8L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8 c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTq3c7LTqfrF6TsNCglwYW5vc2UtMToyIDIg MyAwIDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDpQTWluZ0xpVTsNCglt c28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9u dC1zaWduYXR1cmU6MSAxMzQ3NDIwMTYgMTYgMCAxMDQ4NTc2IDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToitdixZLLTturF6VwoUFwpIjsNCglw YW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDq3 c7LTqfrF6TsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1mb3JtYXQ6b3RoZXI7 DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28tZm9udC1zaWduYXR1cmU6 MSAxMzQ3NDIwMTYgMTYgMCAxMDQ4NTc2IDA7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEC3c7LTqfrF6SI7DQoJcGFub3NlLTE6MiAyIDMgMCAw IDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28tZ2Vu ZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJp YWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MSAxMzQ3NDIwMTYgMTYgMCAx MDQ4NTc2IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEC12LFk stO26sXpXChQXCkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1m YW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtZm9ybWF0Om90aGVyOw0KCW1zby1m b250LXBpdGNoOmF1dG87DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM0NzQy MDE2IDE2IDAgMTA0ODU3NiAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhh bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OrdzstOp+sXp Ow0KCW1zby1oYW5zaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpw DQoJe21hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KCW1zby1o YW5zaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQogLyogUGFnZSBE ZWZpbml0aW9ucyAqLw0KQHBhZ2UNCgl7bXNvLXBhZ2UtYm9yZGVyLXN1cnJv dW5kLWhlYWRlcjpubzsNCgltc28tcGFnZS1ib3JkZXItc3Vycm91bmQtZm9v dGVyOm5vO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEu OXB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7DQoJ bXNvLWhlYWRlci1tYXJnaW46NDIuNTVwdDsNCgltc28tZm9vdGVyLW1hcmdp bjo0OS42cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5TZWN0aW9u MQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoN Cjxib2R5IGxhbmc9WkgtVFcgc3R5bGU9J3RhYi1pbnRlcnZhbDoyNC4wcHQn Pg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+pnCqR7uhprM8c3BhbiBsYW5nPUVOLVVTPn6kQKX3qMa3frjqqvcgqbGt sSCxwL5QILBls2YgpqyxYiCnebNmIK23wEkgt37BWrNxs3Gko6XOfrzLvMuk o7vdPHNwYW4NCnN0eWxlPSdjb2xvcjojRkY5OTAwJz6nVqRPuGfA5zYtMTKt 06TrPC9zcGFuPrROr+C+1qazNS0xMLhVpLir+cTyqcqqurLXpc2mrKRKs2+7 8qZuqrq+97d8sXqko6jTuNW41bbcvHil/qzZpbSr97nZpvGhQyCk0aRqqrqm bq74rqchDQqmcKpHsXGrS6dRsNOpsaVYqNOjeKRIoUazo7jysXqms8P2q1mh Q6XYq2Wl/qzZpHemszQwrmGpsa2xoUaxeqSjpbKlWLrevlChRqhDrmExMKRI tE6mbqN7oUYxMKRIKjQwpLgotE65s7lMuPS2TykqNDCuYT08c3Bhbg0Kc3R5 bGU9J2NvbG9yOmZ1Y2hzaWEnPjE2MDAwpLizb7zLo3imrKRKoUM8L3NwYW4+ IKSjrW6xeqN4pVu3+ar3u1CrT8PSqvehRqV1rW6xeq7jpsyqb8ZRwua+TK/5 tKujfKZhpOiu+LZPs7qkXaVppUio07ftILNzwuq2V7DTo3im0cHzoUMNCjwv c3Bhbj48L3A+DQoNCjxmb3JtIGFjdGlvbj0ibWFpbHRvOnJ1ZXl5ZWhAcGNo b21lLmNvbS50dz9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnO tqQiIG1ldGhvZD1wb3N0DQplbmN0eXBlPSJ0ZXh0L3BsYWluIj4NCg0KPHAg YWxpZ249Y2VudGVyIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MjQuMHB0O2NvbG9yOiMwMDk5RkY7bXNvLWZvbnQta2Vybmlu ZzoxLjBwdDttc28tYW5zaS1sYW5ndWFnZToNClpILVRXJz6n2q1upVukSjwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToyNC4wcHQ7Y29s b3I6Z3JlZW47bXNvLWZvbnQta2VybmluZzoNCjEuMHB0O21zby1hbnNpLWxh bmd1YWdlOlpILVRXJz4gPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjI0LjBwdDsNCm1zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjtjb2xvcjpmdWNoc2lhO21zby1mb250LWtlcm5pbmc6MS4w cHQ7DQptc28tYW5zaS1sYW5ndWFnZTpaSC1UVyc+pf6lwbNzwuq2V7DTqMa3 fjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToyNC4wcHQ7 DQpmb250LWZhbWlseToitdixZLLTturF6VwoUFwpIjtjb2xvcjpibHVlO21z by1mb250LWtlcm5pbmc6MS4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6DQpaSC1U Vyc+IDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToyNC4w cHQ7Y29sb3I6IzAwOTlGRjttc28tZm9udC1rZXJuaW5nOg0KMS4wcHQ7bXNv LWFuc2ktbGFuZ3VhZ2U6WkgtVFcnPrnOtqQ8L3NwYW4+PC9iPiA8L3A+DQoN CjxwIGFsaWduPWNlbnRlciBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7dGV4dC1hbGlnbjpjZW50ZXInPqFAPC9wPg0KDQo8cCBh bGlnbj1jZW50ZXIgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0O3RleHQtYWxpZ246Y2VudGVyJz6hQDwvcD4NCg0KPHAgYWxpZ249 Y2VudGVyIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dDt0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTMuNXB0O2NvbG9yOiNDQzY2RkYnPr3QpMS/77F6rE+nX7vdrW6n2q3M p0u2T6q6s9C3fqX6utA8L3NwYW4+PC9iPjwvcD4NCg0KPHAgYWxpZ249Y2Vu dGVyIHN0eWxlPSdtYXJnaW4tdG9wOjQuNXB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo0LjVwdDsNCm1hcmdpbi1sZWZ0OjBjbTt0ZXh0LWFs aWduOmNlbnRlcjtsaW5lLWhlaWdodDoyMDAlJz48Yj48c3BhbiBsYW5nPUVO LVVTDQpzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToitdix ZLLTturF6VwoUFwpIjtjb2xvcjpibHVlJz48SU5QVVQgVFlQRT0iY2hlY2ti b3giIE5BTUU9IqfarW6vwaj6p0u2T6q6s9C3fqX6utAiIFZBTFVFPSK90KfW pEDCSSI+PC9zcGFuPjwvYj48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox My41cHQ7Y29sb3I6cmVkJz6n2q1ur8Go+qdLtk+qurPQt36l+rrQPC9zcGFu PjwvYj48Yj48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjttc28tYXNjaWkt Zm9udC1mYW1pbHk6DQq3c7LTqfrF6Ttjb2xvcjpyZWQnPiZuYnNwOzwvc3Bh bj48L2I+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxkaXYgYWxpZ249Y2VudGVyPg0KDQo8dGFibGUgYm9yZGVyPTEgY2Vs bHNwYWNpbmc9MSBjZWxscGFkZGluZz0wIHdpZHRoPTY4NyBzdHlsZT0nd2lk dGg6NTE1LjI1cHQ7DQogbXNvLWNlbGxzcGFjaW5nOi43cHQ7bXNvLXBhZGRp bmctYWx0OjBjbSAwY20gMGNtIDBjbScgaGVpZ2h0PTE+DQogPHRyIHN0eWxl PSdoZWlnaHQ6MTUuMHB0Jz4NCiAgPHRkIHdpZHRoPTYyNCBzdHlsZT0nd2lk dGg6NDY4LjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0K ICBoZWlnaHQ6MTUuMHB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4N CiAgPHAgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxi PjxzcGFuIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6kpKTlqW2mVzwvc3Bhbj48 L2I+DQogIDxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9w Pg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NTkzIHN0eWxlPSd3aWR0aDo0NDQu NzVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWln aHQ6MTUuMHB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHA+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48SU5QVVQg VFlQRT0idGV4dCIgU0laRT0iMTQiIE5BTUU9IqSkpOWpbaZXIj48L3NwYW4+ PHNwYW4NCiAgbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OrdzstOp+sXpOw0K ICBjb2xvcjp5ZWxsb3cnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT PiA8L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRyIHN0eWxlPSdo ZWlnaHQ6Ljc1cHQnPg0KICA8dGQgd2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0 NjguMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhl aWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxw IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGln bjpyaWdodDttc28tbGluZS1oZWlnaHQtYWx0Og0KICAuNzVwdCc+PGI+PHNw YW4gc3R5bGU9J2NvbG9yOiM2Njk5MzMnPqnKp088L3NwYW4+PC9iPiA8c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4N CiAgPHRkIHdpZHRoPTU5MyBzdHlsZT0nd2lkdGg6NDQ0Ljc1cHQ7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBi b3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J21zby1s aW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2NvbG9yOnllbGxvdyc+PFNFTEVDVCBOQU1FPSKpyqdPIj4NCjxPUFRJT04g U0VMRUNURUQ+vdC/777cDQo8T1BUSU9OPqhrDQo8T1BUSU9OPqRrDQo8L1NF TEVDVD48L3NwYW4+PHNwYW4NCiAgbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNvLWFzY2lpLWZvbnQtZmFtaWx5 OrdzstOp+sXpOw0KICBjb2xvcjp5ZWxsb3cnPiZuYnNwOyZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTPiA8L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwv dHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6Ljc1cHQnPg0KICA8dGQgd2lkdGg9 NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdo dD0iIzgwODA4MCI+DQogIDxwIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFs aWduOnJpZ2h0O21zby1saW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxiPjxzcGFu DQogIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6mfsTWPC9zcGFuPjwvYj4gPHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogIDwvdGQ+ DQogIDx0ZCB3aWR0aD01OTMgc3R5bGU9J3dpZHRoOjQ0NC43NXB0O3BhZGRp bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcg Ym9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSdtc28t bGluZS1oZWlnaHQtYWx0Oi43NXB0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBFPSJ0ZXh0IiBTSVpFPSI0IiBO QU1FPSKmfsTWIj48L3NwYW4+PGI+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6IzY2OTkzMyc+t7M8c3BhbiBsYW5nPUVOLVVTPigx OLezpUikVyk8L3NwYW4+PC9zcGFuPjwvYj48Yj48c3Bhbg0KICBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO21zby1hc2NpaS1mb250LWZhbWlseToNCiAgt3Oy06n6 xek7Y29sb3I6IzY2OTkzMyc+Jm5ic3A7PC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLVVTPiA8L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRyIHN0 eWxlPSdoZWlnaHQ6Ljc1cHQnPg0KICA8dGQgd2lkdGg9NjI0IHN0eWxlPSd3 aWR0aDo0NjguMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7 DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+ DQogIDxwIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0O21z by1saW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxiPjxzcGFuDQogIHN0eWxlPSdj b2xvcjojNjY5OTMzJz6sUK55PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRo PTU5MyBzdHlsZT0nd2lkdGg6NDQ0Ljc1cHQ7cGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBib3JkZXJjb2xvcmxp Z2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J21zby1saW5lLWhlaWdodC1h bHQ6Ljc1cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnllbGxv dyc+PFNFTEVDVCBOQU1FPSKsUK55Ij4NCjxPUFRJT04gU0VMRUNURUQ+vdC/ 777cDQo8T1BUSU9OPqhkps+ueQ0KPE9QVElPTj6q96T7rnkNCjxPUFRJT04+ wvmkbK55DQo8T1BUSU9OPqWow8mueQ0KPE9QVElPTj634KRsrnkNCjxPUFRJ T04+s0Kka655DQo8T1BUSU9OPqTRrGmueQ0KPE9QVElPTj6k0cPIrnkNCjxP UFRJT04+rmek4q55DQo8T1BUSU9OPryvvX6ueQ0KPE9QVElPTj6k9LJ+rnkN CjxPUFRJT04+wvmzva55DQo8L1NFTEVDVD48L3NwYW4+PC9wPg0KICA8L3Rk Pg0KIDwvdHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6Ljc1cHQnPg0KICA8dGQg d2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3BhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29s b3JsaWdodD0iIzgwODA4MCI+DQogIDxwIGFsaWduPXJpZ2h0IHN0eWxlPSd0 ZXh0LWFsaWduOnJpZ2h0O21zby1saW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxi PjxzcGFuDQogIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6xQqvDqqyqcDwvc3Bh bj48L2I+IDxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9w Pg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NTkzIHN0eWxlPSd3aWR0aDo0NDQu NzVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWln aHQ6Ljc1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBz dHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDouNzVwdCc+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48U0VMRUNUIE5BTUU9IrFCq8Oq rKpwIj4NCjxPUFRJT04gU0VMRUNURUQ+vdC/777cDQo8T1BUSU9OPqW8sUIN CjxPUFRJT04+pHexQg0KPC9TRUxFQ1Q+PC9zcGFuPjxzcGFuDQogIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO21z by1hc2NpaS1mb250LWZhbWlseTq3c7LTqfrF6TsNCiAgY29sb3I6eWVsbG93 Jz4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz4gPC9zcGFu PjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0Oi43 NXB0Jz4NCiAgPHRkIHdpZHRoPTYyNCBzdHlsZT0nd2lkdGg6NDY4LjBwdDtw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1 cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBhbGlnbj1y aWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodDttc28tbGluZS1oZWlnaHQt YWx0Oi43NXB0Jz48Yj48c3Bhbg0KICBzdHlsZT0nY29sb3I6IzY2OTkzMyc+ wr63fjwvc3Bhbj48L2I+IDxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48 L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NTkzIHN0eWxlPSd3 aWR0aDo0NDQuNzVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ow0KICBoZWlnaHQ6Ljc1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAi Pg0KICA8cCBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDouNzVwdCc+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48U0VMRUNUIE5B TUU9IsK+t34iPg0KPE9QVElPTiBTRUxFQ1RFRD690L/vvtwNCjxPUFRJT04+ pLq21KRXr1qx2g0KPE9QVElPTj63frDIpua+UA0KPE9QVElPTj5TT0hPsdoN CjxPUFRJT04+ptukdrftptGqTw0KPE9QVElPTj7Cvrd+sPykaw0KPE9QVElP Tj6uYa54pUSw/A0KPE9QVElPTj6r3bd+pKQNCjxPUFRJT04+vselzQ0KPE9Q VElPTj6o5KVMDQo8L1NFTEVDVD48L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwv dHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6Ljc1cHQnPg0KICA8dGQgd2lkdGg9 NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdo dD0iIzgwODA4MCI+DQogIDxwIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFs aWduOnJpZ2h0Jz48Yj48c3BhbiBzdHlsZT0nY29sb3I6IzY2OTkzMyc+wXC1 uLlxuNw8c3Bhbg0KICBsYW5nPUVOLVVTPiA6IKXVpNE8L3NwYW4+PC9zcGFu PjwvYj48L3A+DQogIDxwIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWdu OnJpZ2h0O21zby1saW5lLWhlaWdodC1hbHQ6Ljc1cHQnPjxiPjxzcGFuDQog IHN0eWxlPSdjb2xvcjojNjY5OTMzJz6m7a5hPC9zcGFuPjwvYj4gPHNwYW4g bGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQog IDx0ZCB3aWR0aD01OTMgc3R5bGU9J3dpZHRoOjQ0NC43NXB0O3BhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9y ZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSdtYXJnaW4t dG9wOjIuMjVwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206Mi4y NXB0O21hcmdpbi1sZWZ0Og0KICAwY207bGluZS1oZWlnaHQ6MTUwJSc+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48SU5QVVQgVFlQ RT0idGV4dCIgU0laRT0iMTQiIE5BTUU9IsFwtbi5cbjcLaXVpNEiPjwvc3Bh bj48c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjttc28tYXNjaWktZm9udC1mYW1pbHk6t3Oy06n6xek7 DQogIGNvbG9yOnllbGxvdyc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4t VVM+IDwvc3Bhbj48L3A+DQogIDxwIHN0eWxlPSdtYXJnaW4tdG9wOjIuMjVw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206Mi4yNXB0O21hcmdp bi1sZWZ0Og0KICAwY207bXNvLWxpbmUtaGVpZ2h0LWFsdDouNzVwdCc+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48SU5QVVQgVFlQ RT0idGV4dCIgU0laRT0iMTQiIE5BTUU9IsFwtbi5cbjcLabtrmEiPjwvc3Bh bj48L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdodDou NzVwdCc+DQogIDx0ZCB3aWR0aD02MjQgc3R5bGU9J3dpZHRoOjQ2OC4wcHQ7 cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43 NXB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgYWxpZ249 cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQ7bXNvLWxpbmUtaGVpZ2h0 LWFsdDouNzVwdCc+PGI+PHNwYW4NCiAgc3R5bGU9J2NvbG9yOiM2Njk5MzMn Pq3dwr6wyr73PC9zcGFuPjwvYj4gPHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQogIDx0ZCB3aWR0aD01OTMgc3R5 bGU9J3dpZHRoOjQ0NC43NXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgw ODA4MCI+DQogIDxwIHN0eWxlPSdtc28tbGluZS1oZWlnaHQtYWx0Oi43NXB0 Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxTRUxF Q1QgTkFNRT0ird2udLDKvvciPg0KPE9QVElPTiBTRUxFQ1RFRD690L/vvtwN CjxPUFRJT04+v/qko7D3pc4NCjxPUFRJT04+vFelW7LEpEel96aspEoNCjxP UFRJT04+s9C3frftptGqTw0KPE9QVElPTj60TqxPt1HByL/6DQo8L1NFTEVD VD48L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRyIHN0eWxlPSdo ZWlnaHQ6Ljc1cHQnPg0KICA8dGQgd2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0 NjguMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhl aWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxw IGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0O21zby1saW5l LWhlaWdodC1hbHQ6Ljc1cHQnPjxiPjxzcGFuDQogIHN0eWxlPSdjb2xvcjoj NjY5OTMzJz6zzKToq0vBcLW4rsm2oTwvc3Bhbj48L2I+IDxzcGFuIGxhbmc9 RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQg d2lkdGg9NTkzIHN0eWxlPSd3aWR0aDo0NDQuNzVwdDtwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1cHQnIGJvcmRlcmNv bG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0nbXNvLWxpbmUtaGVp Z2h0LWFsdDouNzVwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6 eWVsbG93Jz48U0VMRUNUIE5BTUU9IrPMpOirS8FwtbiuybahLaxQtMEiPg0K PE9QVElPTiBTRUxFQ1RFRD690L/vvtwNCjxPUFRJT04+rFC0waRADQo8T1BU SU9OPqxQtMGkRw0KPE9QVElPTj6sULTBpFQNCjxPUFRJT04+rFC0waV8DQo8 T1BUSU9OPqxQtMGkrQ0KPE9QVElPTj6sULTBpLsNCjxPUFRJT04+rFC0waTp DQo8T1BUSU9OPrOjpWmlSA0KPC9TRUxFQ1Q+PFNFTEVDVCBOQU1FPSKzzKTo q0vBcLW4rsm2oS2uyaxxIj4NCjxPUFRJT04gU0VMRUNURUQ+vdC/777cDQo8 T1BUSU9OPqRXpMg5LTEyDQo8T1BUSU9OPqSkpMgxMi0xDQo8T1BUSU9OPqRV pMgxLTUNCjxPUFRJT04+sd+kVzgtMTANCjxPUFRJT04+sd+kVzktMTENCjxP UFRJT04+s6OlaaVIDQo8L1NFTEVDVD48L3NwYW4+PHNwYW4NCiAgbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7bXNv LWFzY2lpLWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KICBjb2xvcjp5ZWxsb3cn PiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPiA8L3NwYW4+ PC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6Ljc1 cHQnPg0KICA8dGQgd2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3Bh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVw dCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIGFsaWduPXJp Z2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0O21zby1saW5lLWhlaWdodC1h bHQ6Ljc1cHQnPjxiPjxzcGFuDQogIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6z zKToq0utsb3Nrsm2oTwvc3Bhbj48L2I+IDxzcGFuIGxhbmc9RU4tVVM+PG86 cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9NTkz IHN0eWxlPSd3aWR0aDo0NDQuNzVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9 IiM4MDgwODAiPg0KICA8cCBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDou NzVwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6eWVsbG93Jz48 U0VMRUNUIE5BTUU9IrPMpOirS62xvc2uybahIj4NCjxPUFRJT04gU0VMRUNU RUQ+vdC/777cDQo8T1BUSU9OPqxQtMGkQA0KPE9QVElPTj6sULTBpEcNCjxP UFRJT04+rFC0waRUDQo8T1BUSU9OPqxQtMGlfA0KPE9QVElPTj6sULTBpK0N CjxPUFRJT04+s6OlaaVIDQo8T1BUSU9OPrCypOkNCjwvU0VMRUNUPjwvc3Bh bj48Yj48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtjb2xvcjoj NjY5OTMzJz6x36RXPHNwYW4gbGFuZz1FTi1VUz43OjMwLTk6MDA8L3NwYW4+ PC9zcGFuPjwvYj48Yj48c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO21z by1hc2NpaS1mb250LWZhbWlseToNCiAgt3Oy06n6xek7Y29sb3I6Izk5MDBD Qyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvYj48c3BhbiBs YW5nPUVOLVVTPiA8L3NwYW4+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRy IHN0eWxlPSdoZWlnaHQ6MTguMHB0Jz4NCiAgPHRkIHdpZHRoPTYyNCBzdHls ZT0nd2lkdGg6NDY4LjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ow0KICBoZWlnaHQ6MTguMHB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4 MDgwIj4NCiAgPHAgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmln aHQnPjxiPjxzcGFuIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6mYad9PC9zcGFu Pg0KICA8L2I+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQogIDwvdGQ+DQogIDx0ZCB3aWR0aD01OTMgc3R5bGU9J3dpZHRoOjQ0 NC43NXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhl aWdodDoxOC4wcHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8 cD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBV VCBUWVBFPSJ0ZXh0IiBTSVpFPSI0OSIgTkFNRT0ipmGnfSI+PC9zcGFuPjwv cD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0OjEyLjc1 cHQnPg0KICA8dGQgd2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3Bh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDoxMi43 NXB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgYWxpZ249 cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPjxzcGFuIHN0eWxl PSdjb2xvcjojNjY5OTMzJz65caRstmyl8zwvc3Bhbj48L2I+DQogIDxzcGFu IGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0K ICA8dGQgd2lkdGg9NTkzIHN0eWxlPSd3aWR0aDo0NDQuNzVwdDtwYWRkaW5n Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6MTIuNzVwdCcg Ym9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOnllbGxvdyc+PElOUFVUIFRZUEU9InRleHQi IFNJWkU9IjQ5IiBOQU1FPSK5caRstmyl8yI+PC9zcGFuPjwvcD4NCiAgPC90 ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0OjMyLjI1cHQnPg0KICA8 dGQgd2lkdGg9NjI0IHN0eWxlPSd3aWR0aDo0NjguMHB0O3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDozMi4yNXB0JyBib3Jk ZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgY2xhc3M9TXNvTm9ybWFs IGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj48c3Bh bg0KICBzdHlsZT0nY29sb3I6IzY2OTkzMyc+q9jEs6jGtrU8L3NwYW4+PC9i PiA8c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAg PC90ZD4NCiAgPHRkIHdpZHRoPTU5MyBzdHlsZT0nd2lkdGg6NDQ0Ljc1cHQ7 cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0OjMy LjI1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBF PSJ0ZXh0IiBTSVpFPSI0OSIgTkFNRT0iq9jEs6jGtrUiPjwvc3Bhbj48L3A+ DQogIDwvdGQ+DQogPC90cj4NCjwvdGFibGU+DQoNCjwvZGl2Pg0KDQo8cCBh bGlnbj1jZW50ZXIgc3R5bGU9J21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbToyLjI1cHQ7DQptYXJnaW4tbGVmdDow Y207dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MTUwJSc+PHNwYW4g bGFuZz1FTi1VUw0Kc3R5bGU9J2NvbG9yOiM2NjAwQ0MnPjxJTlBVVCBUWVBF PSJzdWJtaXQiIEFDVElPTj0ibWFpbHRvOnJ1ZXl5ZWhAcGNob21lLmNvbS50 dz9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIFZBTFVF PSKn2q1upVukSqjGt36l66bxoUGwZaVYuOquxiIgRU5DVFlQRT0idGV4dC9w bGFpbiIgTUVUSE9EPSJwb3N0IiBOQU1FPSK9VLt7Ig0KQUNUSU9OPSJtYWls dG86cnVleXllaEBwY2hvbWUuY29tLnR3P3N1YmplY3Q9p9qtbrDRpVul/qXB s3PC6rZXsNOoxrd+uc62pCIgRU5DVFlQRT0idGV4dC9wbGFpbiINCk1FVEhP RD1wb3N0IEFDVElPTj0ibWFpbHRvOnJ1ZXl5ZWhAcGNob21lLmNvbS50dz9z dWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiDQpFTkNUWVBF PSJ0ZXh0L3BsYWluIiBNRVRIT0Q9cG9zdA0KQUNUSU9OPSJtYWlsdG86cnVl eXllaEBwY2hvbWUuY29tLnR3P3N1YmplY3Q9p9qtbrDRpVul/qXBs3PC6rZX sNOoxrd+uc62pCIgRU5DVFlQRT0idGV4dC9wbGFpbiINCk1FVEhPRD1wb3N0 PjxJTlBVVCBUWVBFPSJyZXNldCIgVkFMVUU9Iq2rtvEiIE5BTUU9Iq2rtvEi Pjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0nbWFyZ2lu LXRvcDoyLjI1cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjIu MjVwdDsNCm1hcmdpbi1sZWZ0OjBjbTt0ZXh0LWFsaWduOmNlbnRlcjtsaW5l LWhlaWdodDoxNTAlJz6hQDwvcD4NCg0KPC9mb3JtPg0KDQo8cCBhbGlnbj1j ZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz6hQCA8L3A+DQoNCjwv ZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4= ------=_NextPart_OwchHPSJbabVvz5i91uMWBPAA-- ------=_NextPart_OwchHPSJbabVvz5i91uMWBP-- From owner-linux-xfs@oss.sgi.com Thu Oct 10 07:56:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 07:56:14 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AEu6tG020528 for ; Thu, 10 Oct 2002 07:56:07 -0700 Received: from exchange1.soton.ac.uk (exchange1.soton.ac.uk [152.78.128.21]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9AEtvPd015190; Thu, 10 Oct 2002 15:55:57 +0100 Received: from exchange2.soton.ac.uk ([152.78.128.12]) by exchange1.soton.ac.uk with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Oct 2002 15:55:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Xfs_force_shutdown on recent XFS CVS Date: Thu, 10 Oct 2002 15:55:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs_force_shutdown on recent XFS CVS Thread-Index: AcJwbNpe/DScCkvnQSydJ2jFDuhK6w== From: "Hardy I.D." To: Cc: X-OriginalArrivalTime: 10 Oct 2002 14:55:57.0328 (UTC) FILETIME=[23BF4900:01C2706D] X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=1.1, required 5, DOUBLE_CAPSWORD) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9AEu7tG020529 X-archive-position: 894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Hi, Yesterday I rebooted a server with a recent XFS CVS (downloaded/compiled Tuesday of this week; the kernel reports at boot time - 'SGI XFS CVS-10/08/02:05 with quota, no debug enabled'. Since then the kernel has shut down the one XFS filesystem on this server: Oct 10 14:22:10 blue01 kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xc01d9138 Oct 10 14:22:10 blue01 kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Oct 10 14:22:10 blue01 kernel: Please umount the filesystem, and rectify the problem(s) I've rebooted, ran xfs_check (and xfs_repair, which was necessary on the first occasion, the 2nd time - above the 'xfs_check' was clean) and remounted the filesystem OK. Is there a possible problem with this CVS that would explain this, I was running (and have now reverted back to a XFS CVS kernel a few weeks old (SGI XFS CVS-09/15/02:17 with quota, no debug enabled). I've not seen the 'xfs_force_shutdown' problem before but have had repeated system panics/lock ups. - though I guess it maybe that recent CVS is better able to trap errors within the XFS code? The server is a NFS server with no user code running directly on it. The filesystem in question is a RAID 0 'md' stripe across 2 HW RAID5 units (~1 Tbyte in size). Regards and thanks for any suggestions. Ian Hardy Information Systems Services Southampton University UK From owner-linux-xfs@oss.sgi.com Thu Oct 10 10:25:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 10:25:46 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AHPZtG000914 for ; Thu, 10 Oct 2002 10:25:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA78824; Thu, 10 Oct 2002 12:25:26 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA44774; Thu, 10 Oct 2002 12:25:24 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9AHNii09812; Thu, 10 Oct 2002 12:23:44 -0500 Subject: Re: Xfs_force_shutdown on recent XFS CVS From: Steve Lord To: "Hardy I.D." Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Oct 2002 12:23:43 -0500 Message-Id: <1034270623.1400.162.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 09:55, Hardy I.D. wrote: > Hi, > > Yesterday I rebooted a server with a recent XFS CVS (downloaded/compiled > Tuesday of this week; the kernel reports at boot time - 'SGI XFS > CVS-10/08/02:05 with quota, no debug enabled'. Since then the kernel has > shut down the one XFS filesystem on this server: > > Oct 10 14:22:10 blue01 kernel: xfs_force_shutdown(md(9,0),0x8) called > from line 1041 of file xfs_trans.c. Return address = 0xc01d9138 > Oct 10 14:22:10 blue01 kernel: Corruption of in-memory data detected. > Shutting down filesystem: md(9,0) > Oct 10 14:22:10 blue01 kernel: Please umount the filesystem, and rectify > the problem(s) > > I've rebooted, ran xfs_check (and xfs_repair, which was necessary on the > first occasion, the 2nd time - above the 'xfs_check' was clean) and > remounted the filesystem OK. Ian, did you run xfs_check and repair before mounting the fs or after? You should mount again after reboot, then run check. The in memory corruption error means it failed an internal check on a memory buffer, not that it had found bad data on the disk. If you have the check/repair output, please send it, but there is no real way to tell if the issues in it were from running the commands with a dirty log or not. We really need to improve that particular trace message, there are 80 some places it could have originated. Lets see if we can do something about that. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 10 12:11:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 12:11:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AJBbtG006598 for ; Thu, 10 Oct 2002 12:11:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA94912 for ; Thu, 10 Oct 2002 14:11:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA02364 for ; Thu, 10 Oct 2002 14:11:32 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9AJ9pd12773; Thu, 10 Oct 2002 14:09:51 -0500 Message-Id: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> Date: Thu, 10 Oct 2002 14:09:51 -0500 Subject: TAKE - make xfs's in memory extents host byte ordered To: linux-xfs@oss.sgi.com X-archive-position: 896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Switch xfs from using a big endian internal representation for the in memory copy of extents to a host byte order representation. The internal extents are read in once, then modified seperately from the on disk ones. Since we search and manipulate the extents multiple times, it is cheaper to convert them to host byte order once and then keep them in that format. Worth about 5 to 10% reduction in cpu time for some loads. Complicated by the fact that the in memory extents are written out to the log sometimes, and when expanding extents are used to write out the initial block of extents. There is no on disk format change here. Steve Date: Thu Oct 10 12:09:44 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129646a linux/fs/xfs/xfsidbg.c - 1.204 - use disk based extent functions linux/fs/xfs/xfs_inode_item.c - 1.105 - when formating an inode item with extents in the inode, endian flip the extents before they go out to the log. Doing this here rather than in recovery avoids us having to version the log. linux/fs/xfs/xfs_inode_item.h - 1.40 - extend inode_item structure to contain an attribute extents buffer linux/fs/xfs/xfs_bmap_btree.h - 1.53 - prototypes for disk format extent functions linux/fs/xfs/xfs_bmap_btree.c - 1.127 - define and use different bmbt functions depending on if we are manipulating disk or host byte ordered extents. Only define the second set of functions as different if we are on a little endian host. linux/fs/xfs/xfs_btree.c - 1.100 - use disk format extent functions linux/fs/xfs/xfs_inode.c - 1.354 - in xfs_iformat_extents and xfs_iextents_copy, do endian conversion linux/fs/xfs/xfs_inode.h - 1.172 - prototype change linux/fs/xfs/xfs_bmap.c - 1.294 - endian flip extents when reading in from disk, and when going from in inode extents to a leaf block of extents. From owner-linux-xfs@oss.sgi.com Thu Oct 10 12:33:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 12:33:09 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AJX6tG007236 for ; Thu, 10 Oct 2002 12:33:06 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 734BE149A5; Thu, 10 Oct 2002 21:33:00 +0200 (MEST) Date: Thu, 10 Oct 2002 21:32:59 +0200 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - make xfs's in memory extents host byte ordered Message-ID: <20021010213259.A23019@wotan.suse.de> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Thu, Oct 10, 2002 at 02:09:51PM -0500, Steve Lord wrote: > Switch xfs from using a big endian internal representation for > the in memory copy of extents to a host byte order representation. > The internal extents are read in once, then modified seperately > from the on disk ones. Since we search and manipulate the extents > multiple times, it is cheaper to convert them to host byte order > once and then keep them in that format. Worth about 5 to 10% > reduction in cpu time for some loads. Complicated by the fact > that the in memory extents are written out to the log sometimes, > and when expanding extents are used to write out the initial > block of extents. That is quite surprising. BSWAP (= htonl) is a single cycle on Athlon. On Intel it's likely similar. When you do it for 64bit it's a bit more expensive, but not much when you use BSWAP and shift. Are you sure it's just not bogus code generated by the compiler ? Perhaps some problem with the way your 64bit conversion works (does it use BSWAP for the 64bit conversion too?) BSWAP should be only used when you compile the kernel for 586+ So i386 compiled generic kernels will be slower too. -Andi From owner-linux-xfs@oss.sgi.com Thu Oct 10 13:07:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 13:07:08 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AK73tG007969 for ; Thu, 10 Oct 2002 13:07:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA86960 for ; Thu, 10 Oct 2002 15:06:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA20556; Thu, 10 Oct 2002 15:06:58 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9AK5Gi16476; Thu, 10 Oct 2002 15:05:16 -0500 Subject: Re: TAKE - make xfs's in memory extents host byte ordered From: Steve Lord To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Oct 2002 15:05:16 -0500 Message-Id: <1034280316.1416.221.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 14:09, Steve Lord wrote: > Switch xfs from using a big endian internal representation for > the in memory copy of extents to a host byte order representation. > The internal extents are read in once, then modified seperately > from the on disk ones. Since we search and manipulate the extents > multiple times, it is cheaper to convert them to host byte order > once and then keep them in that format. Worth about 5 to 10% > reduction in cpu time for some loads. Complicated by the fact > that the in memory extents are written out to the log sometimes, > and when expanding extents are used to write out the initial > block of extents. > > There is no on disk format change here. OK, so hold off on doing a cvs update with this for a while, my crash tests keep running OK, but one of my other machines has some corruption. It has other changes in the kernel which could be the cause, but you never know.... Steve > > Steve > > > Date: Thu Oct 10 12:09:44 PDT 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:129646a > linux/fs/xfs/xfsidbg.c - 1.204 > - use disk based extent functions > > linux/fs/xfs/xfs_inode_item.c - 1.105 > - when formating an inode item with extents in the inode, endian > flip the extents before they go out to the log. Doing this here > rather than in recovery avoids us having to version the log. > > linux/fs/xfs/xfs_inode_item.h - 1.40 > - extend inode_item structure to contain an attribute extents buffer > > linux/fs/xfs/xfs_bmap_btree.h - 1.53 > - prototypes for disk format extent functions > > linux/fs/xfs/xfs_bmap_btree.c - 1.127 > - define and use different bmbt functions depending on if we are > manipulating disk or host byte ordered extents. Only define the > second set of functions as different if we are on a little endian > host. > > linux/fs/xfs/xfs_btree.c - 1.100 > - use disk format extent functions > > linux/fs/xfs/xfs_inode.c - 1.354 > - in xfs_iformat_extents and xfs_iextents_copy, do endian conversion > > linux/fs/xfs/xfs_inode.h - 1.172 > - prototype change > > linux/fs/xfs/xfs_bmap.c - 1.294 > - endian flip extents when reading in from disk, and when > going from in inode extents to a leaf block of extents. > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 10 13:28:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 13:28:57 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AKSntG008485 for ; Thu, 10 Oct 2002 13:28:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA10010 for ; Thu, 10 Oct 2002 15:28:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA07799 for ; Thu, 10 Oct 2002 15:28:43 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9AKQDb09108; Thu, 10 Oct 2002 15:26:13 -0500 Message-Id: <200210102026.g9AKQDb09108@stout.americas.sgi.com> Date: Thu, 10 Oct 2002 15:26:13 -0500 Subject: TAKE - Re-sync pagebuf flags in xfsidbg X-archive-position: 899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Re-sync pagebuf flags in xfsidbg (missed last time...) Date: Thu Oct 10 13:26:04 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129660a linux/fs/xfs/xfsidbg.c - 1.205 - Re-sync pagebuf flags in xfsidbg (missed last time...) From owner-linux-xfs@oss.sgi.com Thu Oct 10 15:31:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 15:31:58 -0700 (PDT) Received: from mta1.sucs.soton.ac.uk (mta1.sucs.soton.ac.uk [152.78.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AMVqtG014019 for ; Thu, 10 Oct 2002 15:31:52 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by mta1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9AMVkP9029027; Thu, 10 Oct 2002 23:31:46 +0100 Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id XAA21735; Thu, 10 Oct 2002 23:31:45 +0100 From: X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f To: Steve Lord Subject: Re: Xfs_force_shutdown on recent XFS CVS Message-ID: <1034289105.3da5ffd17e21c@webmail.soton.ac.uk> Date: Thu, 10 Oct 2002 23:31:45 +0100 (BST) Cc: "Hardy I.D." , linux-xfs@oss.sgi.com References: <1034270623.1400.162.camel@jen.americas.sgi.com> In-Reply-To: <1034270623.1400.162.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.186.250.216 X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME) X-archive-position: 900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs On 10 Oct 2002 12:23:43 -0500: Steve Lord Wrote: > > Ian, did you run xfs_check and repair before mounting the fs or > after? You should mount again after reboot, then run check. > The in memory corruption error means it failed an internal check > on a memory buffer, not that it had found bad data on the disk. > > If you have the check/repair output, please send it, but there is > no real way to tell if the issues in it were from running the > commands with a dirty log or not. > > We really need to improve that particular trace message, there > are 80 some places it could have originated. Lets see if we > can do something about that. > > Steve > > Steve, thanks as always for your reply. Yes, the server was rebooted, and the filesystem mounted and unmounted prior to running xfs_check/repair. Also, a 'xfs_fsr' was run when we upgraded the kernel (on an idle system), the system was then rebooted and 'xfs_check' ran on the filesystem (clean) before the server was but back into service (and therefore prior to the 2 filesystem shutdowns); I can therefore be confident that any FS corruption occurred while running the new (Wed 8th) XFS CVS kernel. Here's the output from the xfs_check/xfs_repair runs following the first filesystem shutdown (xfs_clean was clean following the 2nd shutdown). ..... (sorry I missed capturing the top of this xfs_check session, though I think this was near the start). bad magic number 0x2020 for inode 19701440 bad magic number 0x2020 for inode 19701441 bad magic number 0x2020 for inode 19701442 bad magic number 0x2031 for inode 19701443 bad magic number 0x3137 for inode 19701444 bad magic number 0x372e for inode 19701445 bad magic number 0x2e33 for inode 19701446 bad magic number 0x3030 for inode 19701447 bad magic number 0x3034 for inode 19701448 bad magic number 0x3832 for inode 19701449 bad magic number 0x3030 for inode 19701450 bad magic number 0x3933 for inode 19701451 bad magic number 0x3832 for inode 19701452 bad magic number 0x3233 for inode 19701453 bad magic number 0x3836 for inode 19701454 bad magic number 0x3733 for inode 19701455 bad magic number 0x3539 for inode 19701456 bad magic number 0x3435 for inode 19701457 bad magic number 0x3736 for inode 19701458 bad magic number 0x3331 for inode 19701459 bad magic number 0x3520 for inode 19701460 bad magic number 0x2020 for inode 19701461 bad magic number 0x2020 for inode 19701462 bad magic number 0x2020 for inode 19701463 bad magic number 0x2020 for inode 19701464 bad magic number 0x202d for inode 19701465 bad magic number 0x2d30 for inode 19701466 bad magic number 0x302e for inode 19701467 bad magic number 0x2e35 for inode 19701468 bad magic number 0x3330 for inode 19701469 bad magic number 0x3737 for inode 19701470 bad magic number 0x3730 for inode 19701471 bad magic number 0x3039 for inode 19701472 bad magic number 0x3032 for inode 19701473 bad magic number 0x3637 for inode 19701474 bad magic number 0x3134 for inode 19701475 bad magic number 0x3630 for inode 19701476 bad magic number 0x3333 for inode 19701477 bad magic number 0x3638 for inode 19701478 bad magic number 0x3735 for inode 19701479 bad magic number 0x3134 for inode 19701480 bad magic number 0x3635 for inode 19701481 bad magic number 0x3333 for inode 19701482 bad magic number 0x3831 for inode 19701483 bad magic number 0x3020 for inode 19701484 bad magic number 0x2020 for inode 19701485 bad magic number 0x2d30 for inode 19701486 bad magic number 0x2020 for inode 19701487 bad magic number 0x2020 for inode 19701488 bad magic number 0x200a for inode 19701489 bad magic number 0xa20 for inode 19701490 bad magic number 0x2020 for inode 19701491 bad magic number 0x2035 for inode 19701492 bad magic number 0x3439 for inode 19701493 bad magic number 0x302e for inode 19701494 bad magic number 0x2e33 for inode 19701495 bad magic number 0x3831 for inode 19701496 bad magic number 0x3935 for inode 19701497 bad magic number 0x3033 for inode 19701498 bad magic number 0x3430 for inode 19701499 bad magic number 0x3737 for inode 19701500 bad magic number 0x3739 for inode 19701501 bad magic number 0x3536 for inode 19701502 bad magic number 0x3639 for inode 19701503 link count mismatch for inode 19701440 (name ?), nlink 0, counted 1 link count mismatch for inode 19701441 (name ?), nlink 0, counted 1 link count mismatch for inode 19701442 (name ?), nlink 0, counted 1 link count mismatch for inode 19701443 (name ?), nlink 0, counted 1 user quota id 39946, have/exp bc 33686153/33685628 ic 377630/377629 user quota id 5102, have/exp ic 57152/57148 sh-2.05a# sh-2.05a# xfs_repair /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 bad magic number 0x2020 on inode 19701440 bad version number 0x31 on inode 19701440 bad inode format in inode 19701440 bad magic number 0x2020 on inode 19701441 bad version number 0x37 on inode 19701441 bad inode format in inode 19701441 bad magic number 0x2020 on inode 19701442 bad version number 0x2e on inode 19701442 bad inode format in inode 19701442 bad magic number 0x2031 on inode 19701443 bad version number 0x32 on inode 19701443 bad inode format in inode 19701443 bad magic number 0x3137 on inode 19701444 bad version number 0x37 on inode 19701444 bad inode format in inode 19701444 bad magic number 0x372e on inode 19701445 bad version number 0x34 on inode 19701445 bad inode format in inode 19701445 bad magic number 0x2e33 on inode 19701446 bad version number 0x34 on inode 19701446 bad inode format in inode 19701446 bad magic number 0x3030 on inode 19701447 bad version number 0x35 on inode 19701447 bad inode format in inode 19701447 bad magic number 0x3034 on inode 19701448 bad version number 0x32 on inode 19701448 bad inode format in inode 19701448 bad magic number 0x3832 on inode 19701449 bad version number 0x34 on inode 19701449 bad inode format in inode 19701449 bad magic number 0x3030 on inode 19701450 bad version number 0x39 on inode 19701450 bad inode format in inode 19701450 bad magic number 0x3933 on inode 19701451 bad version number 0x39 on inode 19701451 bad inode format in inode 19701451 bad magic number 0x3832 on inode 19701452 bad version number 0x37 on inode 19701452 bad inode format in inode 19701452 bad magic number 0x3233 on inode 19701453 bad version number 0x39 on inode 19701453 bad inode format in inode 19701453 bad magic number 0x3836 on inode 19701454 bad version number 0x37 on inode 19701454 bad inode format in inode 19701454 bad magic number 0x3733 on inode 19701455 bad version number 0x35 on inode 19701455 bad inode format in inode 19701455 bad magic number 0x3539 on inode 19701456 bad version number 0x37 on inode 19701456 bad inode format in inode 19701456 bad magic number 0x3435 on inode 19701457 bad version number 0x20 on inode 19701457 bad inode format in inode 19701457 bad magic number 0x3736 on inode 19701458 bad version number 0x20 on inode 19701458 bad inode format in inode 19701458 bad magic number 0x3331 on inode 19701459 bad version number 0x20 on inode 19701459 bad inode format in inode 19701459 bad magic number 0x3520 on inode 19701460 bad version number 0x20 on inode 19701460 bad inode format in inode 19701460 bad magic number 0x2020 on inode 19701461 bad version number 0x20 on inode 19701461 bad inode format in inode 19701461 bad magic number 0x2020 on inode 19701462 bad version number 0x2d on inode 19701462 bad inode format in inode 19701462 bad magic number 0x2020 on inode 19701463 bad version number 0x30 on inode 19701463 bad inode format in inode 19701463 bad magic number 0x2020 on inode 19701464 bad version number 0x2e on inode 19701464 bad inode format in inode 19701464 bad magic number 0x202d on inode 19701465 bad version number 0x36 on inode 19701465 bad inode format in inode 19701465 bad magic number 0x2d30 on inode 19701466 bad version number 0x30 on inode 19701466 bad inode format in inode 19701466 bad magic number 0x302e on inode 19701467 bad version number 0x31 on inode 19701467 bad inode format in inode 19701467 bad magic number 0x2e35 on inode 19701468 bad version number 0x37 on inode 19701468 bad inode format in inode 19701468 bad magic number 0x3330 on inode 19701469 bad version number 0x38 on inode 19701469 bad inode format in inode 19701469 bad magic number 0x3737 on inode 19701470 bad version number 0x32 on inode 19701470 bad inode format in inode 19701470 bad magic number 0x3730 on inode 19701471 bad version number 0x34 on inode 19701471 bad inode format in inode 19701471 bad magic number 0x3039 on inode 19701472 bad version number 0x39 on inode 19701472 bad inode format in inode 19701472 bad magic number 0x3032 on inode 19701473 bad version number 0x34 on inode 19701473 bad inode format in inode 19701473 bad magic number 0x3637 on inode 19701474 bad version number 0x30 on inode 19701474 bad inode format in inode 19701474 bad magic number 0x3134 on inode 19701475 bad version number 0x32 on inode 19701475 bad inode format in inode 19701475 bad magic number 0x3630 on inode 19701476 bad version number 0x34 on inode 19701476 bad inode format in inode 19701476 bad magic number 0x3333 on inode 19701477 bad version number 0x38 on inode 19701477 bad inode format in inode 19701477 bad magic number 0x3638 on inode 19701478 bad version number 0x30 on inode 19701478 bad inode format in inode 19701478 bad magic number 0x3735 on inode 19701479 bad version number 0x36 on inode 19701479 bad inode format in inode 19701479 bad magic number 0x3134 on inode 19701480 bad version number 0x34 on inode 19701480 bad inode format in inode 19701480 bad magic number 0x3635 on inode 19701481 bad version number 0x20 on inode 19701481 bad inode format in inode 19701481 bad magic number 0x3333 on inode 19701482 bad version number 0x20 on inode 19701482 bad inode format in inode 19701482 bad magic number 0x3831 on inode 19701483 bad version number 0x30 on inode 19701483 bad inode format in inode 19701483 bad magic number 0x3020 on inode 19701484 bad version number 0x20 on inode 19701484 bad inode format in inode 19701484 bad magic number 0x2020 on inode 19701485 bad version number 0x20 on inode 19701485 bad inode format in inode 19701485 bad magic number 0x2d30 on inode 19701486 bad version number 0xa on inode 19701486 bad inode format in inode 19701486 bad magic number 0x2020 on inode 19701487 bad version number 0x20 on inode 19701487 bad inode format in inode 19701487 bad magic number 0x2020 on inode 19701488 bad version number 0x20 on inode 19701488 bad inode format in inode 19701488 bad magic number 0x200a on inode 19701489 bad version number 0x35 on inode 19701489 bad inode format in inode 19701489 bad magic number 0xa20 on inode 19701490 bad version number 0x39 on inode 19701490 bad inode format in inode 19701490 bad magic number 0x2020 on inode 19701491 bad version number 0x2e on inode 19701491 bad inode format in inode 19701491 bad magic number 0x2035 on inode 19701492 bad version number 0x33 on inode 19701492 bad inode format in inode 19701492 bad magic number 0x3439 on inode 19701493 bad version number 0x39 on inode 19701493 bad inode format in inode 19701493 bad magic number 0x302e on inode 19701494 bad version number 0x33 on inode 19701494 bad inode format in inode 19701494 bad magic number 0x2e33 on inode 19701495 bad version number 0x37 on inode 19701495 bad inode format in inode 19701495 bad magic number 0x3831 on inode 19701496 bad version number 0x39 on inode 19701496 bad inode format in inode 19701496 bad magic number 0x3935 on inode 19701497 bad version number 0x35 on inode 19701497 bad inode format in inode 19701497 bad magic number 0x3033 on inode 19701498 bad version number 0x37 on inode 19701498 bad inode format in inode 19701498 bad magic number 0x3430 on inode 19701499 bad version number 0x35 on inode 19701499 bad inode format in inode 19701499 bad magic number 0x3737 on inode 19701500 bad version number 0x31 on inode 19701500 bad inode format in inode 19701500 bad magic number 0x3739 on inode 19701501 bad version number 0x36 on inode 19701501 bad inode format in inode 19701501 bad magic number 0x3536 on inode 19701502 bad version number 0x35 on inode 19701502 bad inode format in inode 19701502 bad magic number 0x3639 on inode 19701503 bad version number 0x34 on inode 19701503 bad inode format in inode 19701503 - agno = 3 - agno = 4 - agno = 5 .... removed similar lines - agno = 265 - agno = 266 - agno = 267 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 entry "pltfile-9-75" at block 4 offset 2672 in directory inode 16777499 references non-existent inode 19701440 clearing inode number in entry at offset 2672... entry "nrg-10-75" at block 14 offset 2992 in directory inode 16777499 references non-existent inode 19701442 clearing inode number in entry at offset 2992... entry "output-10-75" at block 14 offset 4040 in directory inode 16777499 references non-existent inode 19701441 clearing inode number in entry at offset 4040... entry "pltfile-10-75" at block 15 offset 2024 in directory inode 16777499 references non-existent inode 19701443 clearing inode number in entry at offset 2024... - agno = 3 - agno = 4 - agno = 5 ... removed lines upto .... - agno = 265 - agno = 266 - agno = 267 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 64 rebuilding directory inode 16777499 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Regards and thanks Ian Hardy Research Services Information Systems Services Southampton University From owner-linux-xfs@oss.sgi.com Thu Oct 10 17:33:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 17:33:25 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B0XCtG016983 for ; Thu, 10 Oct 2002 17:33:13 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.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 RAA04282 for ; Thu, 10 Oct 2002 17:32:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA38508; Thu, 10 Oct 2002 19:22:57 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-7.corp.sgi.com [134.15.64.7]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA00023; Thu, 10 Oct 2002 19:22:55 -0500 (CDT) Subject: Re: Xfs_force_shutdown on recent XFS CVS From: Stephen Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034289105.3da5ffd17e21c@webmail.soton.ac.uk> References: <1034270623.1400.162.camel@jen.americas.sgi.com> <1034289105.3da5ffd17e21c@webmail.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Oct 2002 19:19:08 -0500 Message-Id: <1034295549.1073.10.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 17:31, I.D.Hardy@soton.ac.uk wrote: > > On 10 Oct 2002 12:23:43 -0500: Steve Lord Wrote: > > > > > Ian, did you run xfs_check and repair before mounting the fs or > > after? You should mount again after reboot, then run check. > > The in memory corruption error means it failed an internal check > > on a memory buffer, not that it had found bad data on the disk. > > > > If you have the check/repair output, please send it, but there is > > no real way to tell if the issues in it were from running the > > commands with a dirty log or not. > > > > We really need to improve that particular trace message, there > > are 80 some places it could have originated. Lets see if we > > can do something about that. > > > > Steve > > > > > > Steve, thanks as always for your reply. Yes, the server was rebooted, and the > filesystem mounted and unmounted prior to running xfs_check/repair. Also, > a 'xfs_fsr' was run when we upgraded the kernel (on an idle system), the system > was then rebooted and 'xfs_check' ran on the filesystem (clean) before the > server was but back into service (and therefore prior to the 2 filesystem > shutdowns); I can therefore be confident that any FS corruption occurred while > running the new (Wed 8th) XFS CVS kernel. > > Here's the output from the xfs_check/xfs_repair runs following the first > filesystem shutdown (xfs_clean was clean following the 2nd shutdown). > > ..... (sorry I missed capturing the top of this xfs_check session, though > I think this was near the start). Hmm, you have ascii data on top of inodes by the look of it. So this looks like a rogue write. You have 64 inodes here which look like they were completely overwritten. Working out where this came from is key here. I am not aware of anything which changed recently which might relate to this. Steve > bad magic number 0x2020 for inode 19701440 > bad magic number 0x2020 for inode 19701441 > bad magic number 0x2020 for inode 19701442 > bad magic number 0x2031 for inode 19701443 > bad magic number 0x3137 for inode 19701444 > bad magic number 0x372e for inode 19701445 > bad magic number 0x2e33 for inode 19701446 > bad magic number 0x3030 for inode 19701447 > bad magic number 0x3034 for inode 19701448 > bad magic number 0x3832 for inode 19701449 > bad magic number 0x3030 for inode 19701450 > bad magic number 0x3933 for inode 19701451 > bad magic number 0x3832 for inode 19701452 > bad magic number 0x3233 for inode 19701453 > bad magic number 0x3836 for inode 19701454 > bad magic number 0x3733 for inode 19701455 > bad magic number 0x3539 for inode 19701456 > bad magic number 0x3435 for inode 19701457 > bad magic number 0x3736 for inode 19701458 > bad magic number 0x3331 for inode 19701459 > bad magic number 0x3520 for inode 19701460 > bad magic number 0x2020 for inode 19701461 > bad magic number 0x2020 for inode 19701462 > bad magic number 0x2020 for inode 19701463 > bad magic number 0x2020 for inode 19701464 > bad magic number 0x202d for inode 19701465 > bad magic number 0x2d30 for inode 19701466 > bad magic number 0x302e for inode 19701467 > bad magic number 0x2e35 for inode 19701468 > bad magic number 0x3330 for inode 19701469 > bad magic number 0x3737 for inode 19701470 > bad magic number 0x3730 for inode 19701471 > bad magic number 0x3039 for inode 19701472 > bad magic number 0x3032 for inode 19701473 > bad magic number 0x3637 for inode 19701474 > bad magic number 0x3134 for inode 19701475 > bad magic number 0x3630 for inode 19701476 > bad magic number 0x3333 for inode 19701477 > bad magic number 0x3638 for inode 19701478 > bad magic number 0x3735 for inode 19701479 > bad magic number 0x3134 for inode 19701480 > bad magic number 0x3635 for inode 19701481 > bad magic number 0x3333 for inode 19701482 > bad magic number 0x3831 for inode 19701483 > bad magic number 0x3020 for inode 19701484 > bad magic number 0x2020 for inode 19701485 > bad magic number 0x2d30 for inode 19701486 > bad magic number 0x2020 for inode 19701487 > bad magic number 0x2020 for inode 19701488 > bad magic number 0x200a for inode 19701489 > bad magic number 0xa20 for inode 19701490 > bad magic number 0x2020 for inode 19701491 > bad magic number 0x2035 for inode 19701492 > bad magic number 0x3439 for inode 19701493 > bad magic number 0x302e for inode 19701494 > bad magic number 0x2e33 for inode 19701495 > bad magic number 0x3831 for inode 19701496 > bad magic number 0x3935 for inode 19701497 > bad magic number 0x3033 for inode 19701498 > bad magic number 0x3430 for inode 19701499 > bad magic number 0x3737 for inode 19701500 > bad magic number 0x3739 for inode 19701501 > bad magic number 0x3536 for inode 19701502 > bad magic number 0x3639 for inode 19701503 > link count mismatch for inode 19701440 (name ?), nlink 0, counted 1 > link count mismatch for inode 19701441 (name ?), nlink 0, counted 1 > link count mismatch for inode 19701442 (name ?), nlink 0, counted 1 > link count mismatch for inode 19701443 (name ?), nlink 0, counted 1 > user quota id 39946, have/exp bc 33686153/33685628 ic 377630/377629 > user quota id 5102, have/exp ic 57152/57148 > sh-2.05a# > sh-2.05a# xfs_repair /dev/md0 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > bad magic number 0x2020 on inode 19701440 > bad version number 0x31 on inode 19701440 > bad inode format in inode 19701440 > bad magic number 0x2020 on inode 19701441 > bad version number 0x37 on inode 19701441 > bad inode format in inode 19701441 > bad magic number 0x2020 on inode 19701442 > bad version number 0x2e on inode 19701442 > bad inode format in inode 19701442 > bad magic number 0x2031 on inode 19701443 > bad version number 0x32 on inode 19701443 > bad inode format in inode 19701443 > bad magic number 0x3137 on inode 19701444 > bad version number 0x37 on inode 19701444 > bad inode format in inode 19701444 > bad magic number 0x372e on inode 19701445 > bad version number 0x34 on inode 19701445 > bad inode format in inode 19701445 > bad magic number 0x2e33 on inode 19701446 > bad version number 0x34 on inode 19701446 > bad inode format in inode 19701446 > bad magic number 0x3030 on inode 19701447 > bad version number 0x35 on inode 19701447 > bad inode format in inode 19701447 > bad magic number 0x3034 on inode 19701448 > bad version number 0x32 on inode 19701448 > bad inode format in inode 19701448 > bad magic number 0x3832 on inode 19701449 > bad version number 0x34 on inode 19701449 > bad inode format in inode 19701449 > bad magic number 0x3030 on inode 19701450 > bad version number 0x39 on inode 19701450 > bad inode format in inode 19701450 > bad magic number 0x3933 on inode 19701451 > bad version number 0x39 on inode 19701451 > bad inode format in inode 19701451 > bad magic number 0x3832 on inode 19701452 > bad version number 0x37 on inode 19701452 > bad inode format in inode 19701452 > bad magic number 0x3233 on inode 19701453 > bad version number 0x39 on inode 19701453 > bad inode format in inode 19701453 > bad magic number 0x3836 on inode 19701454 > bad version number 0x37 on inode 19701454 > bad inode format in inode 19701454 > bad magic number 0x3733 on inode 19701455 > bad version number 0x35 on inode 19701455 > bad inode format in inode 19701455 > bad magic number 0x3539 on inode 19701456 > bad version number 0x37 on inode 19701456 > bad inode format in inode 19701456 > bad magic number 0x3435 on inode 19701457 > bad version number 0x20 on inode 19701457 > bad inode format in inode 19701457 > bad magic number 0x3736 on inode 19701458 > bad version number 0x20 on inode 19701458 > bad inode format in inode 19701458 > bad magic number 0x3331 on inode 19701459 > bad version number 0x20 on inode 19701459 > bad inode format in inode 19701459 > bad magic number 0x3520 on inode 19701460 > bad version number 0x20 on inode 19701460 > bad inode format in inode 19701460 > bad magic number 0x2020 on inode 19701461 > bad version number 0x20 on inode 19701461 > bad inode format in inode 19701461 > bad magic number 0x2020 on inode 19701462 > bad version number 0x2d on inode 19701462 > bad inode format in inode 19701462 > bad magic number 0x2020 on inode 19701463 > bad version number 0x30 on inode 19701463 > bad inode format in inode 19701463 > bad magic number 0x2020 on inode 19701464 > bad version number 0x2e on inode 19701464 > bad inode format in inode 19701464 > bad magic number 0x202d on inode 19701465 > bad version number 0x36 on inode 19701465 > bad inode format in inode 19701465 > bad magic number 0x2d30 on inode 19701466 > bad version number 0x30 on inode 19701466 > bad inode format in inode 19701466 > bad magic number 0x302e on inode 19701467 > bad version number 0x31 on inode 19701467 > bad inode format in inode 19701467 > bad magic number 0x2e35 on inode 19701468 > bad version number 0x37 on inode 19701468 > bad inode format in inode 19701468 > bad magic number 0x3330 on inode 19701469 > bad version number 0x38 on inode 19701469 > bad inode format in inode 19701469 > bad magic number 0x3737 on inode 19701470 > bad version number 0x32 on inode 19701470 > bad inode format in inode 19701470 > bad magic number 0x3730 on inode 19701471 > bad version number 0x34 on inode 19701471 > bad inode format in inode 19701471 > bad magic number 0x3039 on inode 19701472 > bad version number 0x39 on inode 19701472 > bad inode format in inode 19701472 > bad magic number 0x3032 on inode 19701473 > bad version number 0x34 on inode 19701473 > bad inode format in inode 19701473 > bad magic number 0x3637 on inode 19701474 > bad version number 0x30 on inode 19701474 > bad inode format in inode 19701474 > bad magic number 0x3134 on inode 19701475 > bad version number 0x32 on inode 19701475 > bad inode format in inode 19701475 > bad magic number 0x3630 on inode 19701476 > bad version number 0x34 on inode 19701476 > bad inode format in inode 19701476 > bad magic number 0x3333 on inode 19701477 > bad version number 0x38 on inode 19701477 > bad inode format in inode 19701477 > bad magic number 0x3638 on inode 19701478 > bad version number 0x30 on inode 19701478 > bad inode format in inode 19701478 > bad magic number 0x3735 on inode 19701479 > bad version number 0x36 on inode 19701479 > bad inode format in inode 19701479 > bad magic number 0x3134 on inode 19701480 > bad version number 0x34 on inode 19701480 > bad inode format in inode 19701480 > bad magic number 0x3635 on inode 19701481 > bad version number 0x20 on inode 19701481 > bad inode format in inode 19701481 > bad magic number 0x3333 on inode 19701482 > bad version number 0x20 on inode 19701482 > bad inode format in inode 19701482 > bad magic number 0x3831 on inode 19701483 > bad version number 0x30 on inode 19701483 > bad inode format in inode 19701483 > bad magic number 0x3020 on inode 19701484 > bad version number 0x20 on inode 19701484 > bad inode format in inode 19701484 > bad magic number 0x2020 on inode 19701485 > bad version number 0x20 on inode 19701485 > bad inode format in inode 19701485 > bad magic number 0x2d30 on inode 19701486 > bad version number 0xa on inode 19701486 > bad inode format in inode 19701486 > bad magic number 0x2020 on inode 19701487 > bad version number 0x20 on inode 19701487 > bad inode format in inode 19701487 > bad magic number 0x2020 on inode 19701488 > bad version number 0x20 on inode 19701488 > bad inode format in inode 19701488 > bad magic number 0x200a on inode 19701489 > bad version number 0x35 on inode 19701489 > bad inode format in inode 19701489 > bad magic number 0xa20 on inode 19701490 > bad version number 0x39 on inode 19701490 > bad inode format in inode 19701490 > bad magic number 0x2020 on inode 19701491 > bad version number 0x2e on inode 19701491 > bad inode format in inode 19701491 > bad magic number 0x2035 on inode 19701492 > bad version number 0x33 on inode 19701492 > bad inode format in inode 19701492 > bad magic number 0x3439 on inode 19701493 > bad version number 0x39 on inode 19701493 > bad inode format in inode 19701493 > bad magic number 0x302e on inode 19701494 > bad version number 0x33 on inode 19701494 > bad inode format in inode 19701494 > bad magic number 0x2e33 on inode 19701495 > bad version number 0x37 on inode 19701495 > bad inode format in inode 19701495 > bad magic number 0x3831 on inode 19701496 > bad version number 0x39 on inode 19701496 > bad inode format in inode 19701496 > bad magic number 0x3935 on inode 19701497 > bad version number 0x35 on inode 19701497 > bad inode format in inode 19701497 > bad magic number 0x3033 on inode 19701498 > bad version number 0x37 on inode 19701498 > bad inode format in inode 19701498 > bad magic number 0x3430 on inode 19701499 > bad version number 0x35 on inode 19701499 > bad inode format in inode 19701499 > bad magic number 0x3737 on inode 19701500 > bad version number 0x31 on inode 19701500 > bad inode format in inode 19701500 > bad magic number 0x3739 on inode 19701501 > bad version number 0x36 on inode 19701501 > bad inode format in inode 19701501 > bad magic number 0x3536 on inode 19701502 > bad version number 0x35 on inode 19701502 > bad inode format in inode 19701502 > bad magic number 0x3639 on inode 19701503 > bad version number 0x34 on inode 19701503 > bad inode format in inode 19701503 > - agno = 3 > - agno = 4 > - agno = 5 > .... removed similar lines > - agno = 265 > - agno = 266 > - agno = 267 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - clearing existing "lost+found" inode > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > entry "pltfile-9-75" at block 4 offset 2672 in directory inode 16777499 > references non-existent inode 19701440 > clearing inode number in entry at offset 2672... > entry "nrg-10-75" at block 14 offset 2992 in directory inode 16777499 > references non-existent inode 19701442 > clearing inode number in entry at offset 2992... > entry "output-10-75" at block 14 offset 4040 in directory inode 16777499 > references non-existent inode 19701441 > clearing inode number in entry at offset 4040... > entry "pltfile-10-75" at block 15 offset 2024 in directory inode 16777499 > references non-existent inode 19701443 > clearing inode number in entry at offset 2024... > - agno = 3 > - agno = 4 > - agno = 5 > ... removed lines upto .... > - agno = 265 > - agno = 266 > - agno = 267 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 64 > rebuilding directory inode 16777499 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > > > Regards and thanks > > Ian Hardy > Research Services > Information Systems Services > Southampton University From owner-linux-xfs@oss.sgi.com Thu Oct 10 17:35:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 17:35:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B0ZXtG017080 for ; Thu, 10 Oct 2002 17:35:35 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA49866; Thu, 10 Oct 2002 19:35:22 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-7.corp.sgi.com [134.15.64.7]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA49901; Thu, 10 Oct 2002 19:35:22 -0500 (CDT) Subject: Re: TAKE - make xfs's in memory extents host byte ordered From: Stephen Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021010213259.A23019@wotan.suse.de> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> <20021010213259.A23019@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Oct 2002 19:31:34 -0500 Message-Id: <1034296295.1074.28.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 14:32, Andi Kleen wrote: > On Thu, Oct 10, 2002 at 02:09:51PM -0500, Steve Lord wrote: > > Switch xfs from using a big endian internal representation for > > the in memory copy of extents to a host byte order representation. > > The internal extents are read in once, then modified seperately > > from the on disk ones. Since we search and manipulate the extents > > multiple times, it is cheaper to convert them to host byte order > > once and then keep them in that format. Worth about 5 to 10% > > reduction in cpu time for some loads. Complicated by the fact > > that the in memory extents are written out to the log sometimes, > > and when expanding extents are used to write out the initial > > block of extents. > > > That is quite surprising. BSWAP (= htonl) is a single cycle on Athlon. > On Intel it's likely similar. > > When you do it for 64bit it's a bit more expensive, but not much when you > use BSWAP and shift. Are you sure it's just not bogus code generated by the > compiler ? Perhaps some problem with the way your 64bit conversion works > (does it use BSWAP for the 64bit conversion too?) > > BSWAP should be only used when you compile the kernel for 586+ > So i386 compiled generic kernels will be slower too. > I should be compiling a 586 kernel (P-III right?), possibly there is something going on in the endian swapping code which is inefficient. we do call down to the kernel primitives that networking uses. The preprocessor output looks horrible, it should all compile down to nothing, but perhaps it is not always. Hmm, need to find someone to take a closer look at this perhaps. One definite number I do have (for a dual 450MHz platform) is cutting cpu time to remove a complete kernel tree from ~3.7 to ~3.5 seconds. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 10 17:39:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 17:39:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B0ditG017547 for ; Thu, 10 Oct 2002 17:39:46 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA54033 for ; Thu, 10 Oct 2002 19:39:39 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-7.corp.sgi.com [134.15.64.7]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA48103; Thu, 10 Oct 2002 19:39:38 -0500 (CDT) Subject: Re: TAKE - make xfs's in memory extents host byte ordered From: Stephen Lord To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034280316.1416.221.camel@jen.americas.sgi.com> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> <1034280316.1416.221.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Oct 2002 19:35:50 -0500 Message-Id: <1034296551.1074.34.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 15:05, Steve Lord wrote: > > OK, so hold off on doing a cvs update with this for a while, my > crash tests keep running OK, but one of my other machines has some > corruption. It has other changes in the kernel which could be the > cause, but you never know.... > > Steve I think my other experiments in the tree were to blame for the issues I saw. If there are any brave souls who want to take the new kernel out for a spin please do. I would be interested in reports from folks running on big endian platforms. Steve From owner-linux-xfs@oss.sgi.com Thu Oct 10 17:50:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 17:50:54 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B0ootG018487 for ; Thu, 10 Oct 2002 17:50:51 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 6F7001DFEB9; Thu, 10 Oct 2002 17:50:50 -0700 (PDT) Date: Thu, 10 Oct 2002 17:50:50 -0700 From: Chris Wedgwood To: "Hardy I.D." Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs_force_shutdown on recent XFS CVS Message-ID: <20021011005050.GA27365@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 904 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Oct 10, 2002 at 03:55:56PM +0100, Hardy I.D. wrote: > Yesterday I rebooted a server with a recent XFS CVS > (downloaded/compiled Tuesday of this week; the kernel reports at > boot time - 'SGI XFS CVS-10/08/02:05 with quota, no debug > enabled'. Since then the kernel has shut down the one XFS filesystem > on this server: What kind of RAM (and how much)? ECC? --cw From owner-linux-xfs@oss.sgi.com Thu Oct 10 18:05:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 18:05:02 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B14wtG018987 for ; Thu, 10 Oct 2002 18:04:59 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 5A85414AA7; Fri, 11 Oct 2002 03:04:52 +0200 (MEST) Date: Fri, 11 Oct 2002 03:04:51 +0200 From: Andi Kleen To: Stephen Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - make xfs's in memory extents host byte ordered Message-ID: <20021011030451.A27822@wotan.suse.de> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> <20021010213259.A23019@wotan.suse.de> <1034296295.1074.28.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1034296295.1074.28.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Try this patch and see if it fixes the performance problem without your XFS change. Without it the 64bit change would not use BSWAP, but some horribly handcoded version. -Andi --- linux/include/linux/byteorder/swab.h-o 2001-07-26 22:45:47.000000000 +0200 +++ linux/include/linux/byteorder/swab.h 2002-10-11 03:03:32.000000000 +0200 @@ -167,11 +167,11 @@ } static __inline__ __u64 __swab64p(__u64 *x) { - return __arch__swab64p(x); + *x = __fswab64(*addr); } static __inline__ void __swab64s(__u64 *addr) { - __arch__swab64s(addr); + *addr = __fswab64(*addr); } #endif /* __BYTEORDER_HAS_U64__ */ From owner-linux-xfs@oss.sgi.com Thu Oct 10 18:09:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 18:09:38 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B19JtG019311 for ; Thu, 10 Oct 2002 18:09:35 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 1E3C514AAF; Fri, 11 Oct 2002 03:09:13 +0200 (MEST) Date: Fri, 11 Oct 2002 03:09:12 +0200 From: Andi Kleen To: Andi Kleen Cc: Stephen Lord , linux-xfs@oss.sgi.com Subject: correct patch was Re: TAKE - make xfs's in memory extents host byte ordered Message-ID: <20021011030912.A1359@wotan.suse.de> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> <20021010213259.A23019@wotan.suse.de> <1034296295.1074.28.camel@laptop.americas.sgi.com> <20021011030451.A27822@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011030451.A27822@wotan.suse.de> User-Agent: Mutt/1.3.22.1i X-archive-position: 906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Last mail had the wrong patch. Here is the correct one that should actually compile --- linux/include/linux/byteorder/swab.h-o 2001-07-26 22:45:47.000000000 +0200 +++ linux/include/linux/byteorder/swab.h 2002-10-11 03:03:32.000000000 +0200 @@ -167,11 +167,11 @@ } static __inline__ __u64 __swab64p(__u64 *x) { - return __arch__swab64p(x); + *x = __fswab64(*x); } static __inline__ void __swab64s(__u64 *addr) { - __arch__swab64s(addr); + *addr = __fswab64(*addr); } #endif /* __BYTEORDER_HAS_U64__ */ From owner-linux-xfs@oss.sgi.com Thu Oct 10 18:22:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 18:22:28 -0700 (PDT) Received: from down.physik.fu-berlin.de (down.physik.fu-berlin.de [160.45.34.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B1MJtG020031 for ; Thu, 10 Oct 2002 18:22:25 -0700 Received: (from thimm@localhost) by down.physik.fu-berlin.de (8.9.3/8.9.1) id DAA1132289; Fri, 11 Oct 2002 03:22:12 +0200 (CEST) Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9B17EOB004385; Fri, 11 Oct 2002 03:07:14 +0200 Date: Fri, 11 Oct 2002 03:07:13 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Cc: David Greaves Subject: [2.4.18-14SGI_XFS_1.2a1] root xfs filesystem executable bits bug comeback? Message-ID: <20021011010713.GA4254@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Lines: 18 X-archive-position: 907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs The bug fixed in http://marc.theaimsgroup.com/?l=linux-xfs&m=103001217021455&w=2 seems to have come back. An XFS root mounted partition returns always true on all files with "test -x". Non-root mounted XFS partitions are OK. At first sight the patch discussed in http://marc.theaimsgroup.com/?l=linux-xfs&m=103001217021455&w=2 seems to be in place. The bug seems to only trigger autofs-with-filemaps failures (as autofs checks the bit for deciding whether the files are maps or programs). ldap based autofs or non-autofs setups let the bug pass unobserved. Help! ;) -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Thu Oct 10 18:27:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 18:27:34 -0700 (PDT) Received: from down.physik.fu-berlin.de (down.physik.fu-berlin.de [160.45.34.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B1ROtG020230 for ; Thu, 10 Oct 2002 18:27:25 -0700 Received: (from thimm@localhost) by down.physik.fu-berlin.de (8.9.3/8.9.1) id DAA1141604; Fri, 11 Oct 2002 03:22:09 +0200 (CEST) Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9AJMQDo011141; Thu, 10 Oct 2002 21:22:26 +0200 Date: Thu, 10 Oct 2002 21:22:26 +0200 From: Axel Thimm To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: 1.2 PreRelease avaliable Message-ID: <20021010192226.GA10689@bonzo.nirvana> References: <1033780525.2804.41.camel@funky> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033780525.2804.41.camel@funky> User-Agent: Mutt/1.4i Lines: 71 X-archive-position: 908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs First of all thanks for spinning a RedHat installer, and also that fast! Good news: + The supplied kernel sources seem to work very well. + The installer does work when installing a minimal system. Having a bootable system with XFS-fs and ssh is already very helpfull. :) Bugs: - The installer will not work if you try to install "custom->everything". After having completed 268 of 1468 packages (754MB of 4691MB) the installer chokes on anaconda: > There was an error installing anaconda-8.0-XFS_1. This can > indicate media failure, lack of disk space, and/or hardware > problems. This is a fatal error and your install will be aborted. > Please verify your media and try your install again. > > Press the OK button to reboot your system. anaconda is 9.276 KBytes and I switched to the shell console and verified that all partitions had enough space left (smallest was /boot and had 45M). - I also tried a network install for XFS "custom->everything" which aborted in a python exception of anaconda (something about inappropriate numers of arguments passed - sorry I didn't dump the error to a diskette). Note that I did checked the media to be OK and also confirmed this behaviour on another station. Furthermore the RedHat vanilla installer works on those machines with "custom->everything", On Fri, Oct 04, 2002 at 08:15:19PM -0500, Russell Cattelan wrote: > Ok so we are making progress toward actually getting a 1.2 release > ready. > ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/ > > Currently the for this pre-release only a single patch'em all patch is > available. The command are split up as usual into rpm's src.rpm's and > tar balls. > > We are still chasing several bugs in this code base, they are very > obscure end case problems so most people won't hit them. > > Please pound on, run over, throw things etc and report problems, success > weather conditions. > > The installer iso is also available. I will install a system that looks > and feels similar to a RedHat (tm) 8.0 system. > NOTE NOTE NOTE > This is probably going to be the only spin of the installer iso, > as the amount of effort is not trivial. > > A few known problems exist and will probably not be fixed unless > somebody wants to send in a fix. > 1) Grud does not install correctly during the install, anybody > wishing to use grub should select lilo initially for the boot loader > and them install grub once the system is up. > > 2) Upgrades on system with labels in the fstab do not work, this is > problem with anaconda and is not easily fixed. The workaround for this > is to change the fstab to contain the actual device names before > attempting the upgrade. > > 3) The text version of the installer is not able to do partitioning. > This is probably a trivial bug in anaconda but we just don't have time > to look at it. > > -Russell Cattelan > > -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Thu Oct 10 18:40:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 18:40:57 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B1emtG020999 for ; Thu, 10 Oct 2002 18:40:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 183EB1E3CFA; Thu, 10 Oct 2002 18:40:47 -0700 (PDT) Date: Thu, 10 Oct 2002 18:40:47 -0700 From: Chris Wedgwood To: Axel Thimm Cc: linux-xfs@oss.sgi.com, David Greaves Subject: Re: [2.4.18-14SGI_XFS_1.2a1] root xfs filesystem executable bits bug comeback? Message-ID: <20021011014047.GA27651@tapu.f00f.org> References: <20021011010713.GA4254@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011010713.GA4254@bonzo.nirvana> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Oct 11, 2002 at 03:07:13AM +0200, Axel Thimm wrote: An XFS root mounted partition returns always true on all files with "test -x". Non-root mounted XFS partitions are OK. What kernel version(s)? charon:~# df -Th . Filesystem Type Size Used Avail Use% Mounted on /dev/hdb2 xfs 4.7G 2.6G 2.2G 55% / charon:~# touch newfile charon:~# chmod -x newfile charon:~# if test -x newfile ; then echo x ; fi charon:~# chmod +x newfile charon:~# if test -x newfile ; then echo xxx ; fi xxx charon:~# uname -r 2.4.19-xfs-rmap14b --cw From owner-linux-xfs@oss.sgi.com Thu Oct 10 19:04:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 19:04:50 -0700 (PDT) Received: from down.physik.fu-berlin.de (down.physik.fu-berlin.de [160.45.34.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B24gtG021594 for ; Thu, 10 Oct 2002 19:04:43 -0700 Received: (from thimm@localhost) by down.physik.fu-berlin.de (8.9.3/8.9.1) id EAA1144816; Fri, 11 Oct 2002 04:04:38 +0200 (CEST) Date: Fri, 11 Oct 2002 04:04:37 +0200 From: Axel Thimm To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com, David Greaves Subject: Re: [2.4.18-14SGI_XFS_1.2a1] root xfs filesystem executable bits bug comeback? Message-ID: <20021011020437.GA1144622@down.physik.fu-berlin.de> References: <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011014047.GA27651@tapu.f00f.org> User-Agent: Mutt/1.3.25i X-archive-position: 910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs On Thu, Oct 10, 2002 at 06:40:47PM -0700, Chris Wedgwood wrote: > On Fri, Oct 11, 2002 at 03:07:13AM +0200, Axel Thimm wrote: > > An XFS root mounted partition returns always true on all files > with "test -x". Non-root mounted XFS partitions are OK. > > What kernel version(s)? The one mentioned in the subject, which is the prerelease version for SGI_XFS_1.2. As I undestand it is is o the RedHat 8.0 kernel (2.4.18-14) with o missing ACL/Quota bits and o XFS-CVS from 30th september (?) The bug came to live with the previous SGI Release, was silenced at the end of June and now seems to be back again. In between I was using -jp14 kernels with xfs which did not have this behaviour. > charon:~# df -Th . > Filesystem Type Size Used Avail Use% Mounted on > /dev/hdb2 xfs 4.7G 2.6G 2.2G 55% / > charon:~# touch newfile > charon:~# chmod -x newfile > charon:~# if test -x newfile ; then echo x ; fi > charon:~# chmod +x newfile > charon:~# if test -x newfile ; then echo xxx ; fi > xxx > charon:~# uname -r > 2.4.19-xfs-rmap14b -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Thu Oct 10 20:11:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 20:11:10 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B3B3tG025138 for ; Thu, 10 Oct 2002 20:11:05 -0700 Received: (qmail 30938 invoked by uid 1000); 11 Oct 2002 03:26:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Oct 2002 03:26:25 -0000 Date: Fri, 11 Oct 2002 06:26:25 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: XFS 1.1 unlink() weirdness Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi We run a 2.4.9-31SGI_XFS_1.1 based server. While the free space got bellow 85% we observed that almost every operation on our XFS partition was slower. This should be somewhat normal when having FSs with small free space. The weird thing is if I unlink() a file which has been created a long time ago (when the FS had 60% disk free) it deletes it instantly (even if having > 800 MB size). But if I delete a 50mb file created 3 days ago it takes almost a minute ?! Is that normal ? :) Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Oct 10 23:32:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Oct 2002 23:32:29 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B6WNtG027021 for ; Thu, 10 Oct 2002 23:32:24 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9B6WEPd007422; Fri, 11 Oct 2002 07:32:15 +0100 Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id HAA22786; Fri, 11 Oct 2002 07:32:14 +0100 From: X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f To: Chris Wedgwood Subject: Re: Xfs_force_shutdown on recent XFS CVS Message-ID: <1034317934.3da6706ea6f3d@webmail.soton.ac.uk> Date: Fri, 11 Oct 2002 07:32:14 +0100 (BST) Cc: "Hardy I.D." , linux-xfs@oss.sgi.com References: <20021011005050.GA27365@tapu.f00f.org> In-Reply-To: <20021011005050.GA27365@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.182.228.54 X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME) X-archive-position: 912 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Quoting Chris Wedgwood : > On Thu, Oct 10, 2002 at 03:55:56PM +0100, Hardy I.D. wrote: > > > Yesterday I rebooted a server with a recent XFS CVS > > (downloaded/compiled Tuesday of this week; the kernel reports at > > boot time - 'SGI XFS CVS-10/08/02:05 with quota, no debug > > enabled'. Since then the kernel has shut down the one XFS filesystem > > on this server: > > What kind of RAM (and how much)? ECC? > > > --cw > Registered ECC, 1Gbyte on a SuperMicro 370DLE Motherboard with 2 Pentium III processors. Ian From owner-linux-xfs@oss.sgi.com Fri Oct 11 02:50:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 02:50:40 -0700 (PDT) Received: from atlas.cc.itu.edu.tr (atlas.cc.itu.edu.tr [160.75.2.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B9oQtG012327 for ; Fri, 11 Oct 2002 02:50:33 -0700 Received: from aontws4044.cc.itu.edu.tr (AONTWS4044.cc.itu.edu.tr [160.75.5.44]) by atlas.cc.itu.edu.tr (8.11.6/8.11.2) with SMTP id g9B9o8012331 for ; Fri, 11 Oct 2002 12:50:08 +0300 Date: Fri, 11 Oct 2002 12:44:32 +0300 From: 辝ref Tufan 辝n To: linux-xfs@oss.sgi.com Subject: XFS 1.2Pre and nfs problem Message-Id: <20021011124432.253ca55a.tufan@itu.edu.tr> Organization: ITU-CC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-redhat-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 X-MIME-Autoconverted: from 8bit to quoted-printable by atlas.cc.itu.edu.tr id g9B9o8012331 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9B9odtG012331 X-archive-position: 913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tufan@itu.edu.tr Precedence: bulk X-list: linux-xfs I have a nfs server running XFS. I have problems with 2.4.19+xfs 1.2pre kernels. Nfsd processes are getting stuck at state D. I have kdb and got a back trace of one the stuck nfsd processes. System : RH 7.1 NFS-Utils : Was Red Hat original , upgraded to 1.0.1 the same happens. Using LVM and qlogic 2100 HBA. XFS volumes are accessible through HBA.. First NFSD got stuck at D state ---------------------------------------- [root@lnxsrv2 /root]# ps -eo pid,stat,args,wchan | grep nfs 1237 SW [nfsd] svc_recv 1238 SW [nfsd] svc_recv 1239 SW [nfsd] svc_recv 1240 SW [nfsd] svc_recv 1241 SW [nfsd] svc_recv 1242 SW [nfsd] svc_recv 1243 SW [nfsd] svc_recv 1244 SW [nfsd] svc_recv 1245 SW [nfsd] svc_recv 1246 SW [nfsd] svc_recv 1247 SW [nfsd] svc_recv 1248 SW [nfsd] svc_recv 1249 SW [nfsd] svc_recv 1250 SW [nfsd] svc_recv 1251 SW [nfsd] svc_recv 1252 DW [nfsd] down 2321 S grep nfs pipe_wait ALL NFSD processes got stuck at D state ---------------------------------------------------- [root@lnxsrv2 /root]# ps -eo pid,stat,args,wchan | grep nfs 1237 DW [nfsd] exp_readlock 1238 DW [nfsd] exp_readlock 1239 DW [nfsd] exp_readlock 1240 DW [nfsd] exp_readlock 1241 DW [nfsd] exp_readlock 1242 DW [nfsd] exp_readlock 1243 DW [nfsd] exp_readlock 1244 DW [nfsd] exp_readlock 1245 DW [nfsd] exp_readlock 1246 DW [nfsd] exp_readlock 1247 DW [nfsd] exp_readlock 1248 DW [nfsd] exp_readlock 1249 DW [nfsd] exp_readlock 1250 DW [nfsd] exp_readlock 1251 DW [nfsd] exp_readlock 1252 DW [nfsd] down 3072 S grep nfs pipe_wait KDB back trace ------------------------------------ 0xc6d11b1c 0xc0107826 __down+0x68 kernel .text 0xc0100000 0xc0107710 0xc0107890 0xc6d11b38 0xc01079d4 __down_failed+0x8 (0xc71acecc, 0xc01fc0c2, 0xc71acec0, 0x15, 0x400) kernel .text 0xc0100000 0xc01079cc 0xc01079d8 0xc6d11b48 0xc01fe453 .text.lock.page_buf_locking+0xf kernel .text 0xc0100000 0xc01fe444 0xc01fe460 0xc6d11b48 0xc01fe2e9 pagebuf_lock+0x39 (0xc71acec0, 0x15, 0x400, 0x1) kernel .text 0xc0100000 0xc01fe2b0 0xc01fe2f0 0xc6d11b50 0xc01fc0c2 _pagebuf_find+0x192 (0xc12cf3c0, 0x800002, 0x0, 0x200, 0x22205) kernel .text 0xc0100000 0xc01fbf30 0xc01fc110 0xc6d11b74 0xc01fc1a8 pagebuf_get+0x68 (0xc12cf3c0, 0x800002, 0x0, 0x1, 0x22205) kernel .text 0xc0100000 0xc01fc140 0xc01fc260 0xc6d11ba4 0xc01f1ffb xfs_trans_read_buf+0x1eb (0xc84ed400, 0xc2c60b68, 0xc12cf3c0, 0x800002, 0x0) kernel .text 0xc0100000 0xc01f1e10 0xc01f2140 0xc6d11bcc 0xc01db0d3 xfs_ialloc_read_agi+0x43 (0xc84ed400, 0xc2c60b68, 0x1, 0xc6d11c2c, 0xc6d11c2c) kernel .text 0xc0100000 0xc01db090 0xc01db160 0xc6d11c04 0xc01d9f32 xfs_ialloc_ag_select+0x232 (0xc2c60b68, 0x111d8ee, 0x0, 0xc1ed, 0x1) kernel .text 0xc0100000 0xc01d9d00 0xc01d9fc0 0xc6d11c44 0xc01da01c xfs_dialloc+0x5c (0xc2c60b68, 0x111d8ee, 0x0, 0xc1ed, 0x1) kernel .text 0xc0100000 0xc01f3100 0xc01f3380 0xc6d11db4 0xc01f7540 xfs_create+0x2c0 (0xc4e1d828, 0xce15fc60, 0xc6d11e5c, 0xc6d11e58, 0x0) kernel .text 0xc0100000 0xc01f7280 0xc01f7790 0xc6d11e40 0xc0201eca linvfs_mknod+0x11a (0xc5253a80, 0xce15fc60, 0xc1ed, 0x0, 0x0) kernel .text 0xc0100000 0xc0201db0 0xc0202020 0xc6d11ee0 0xc0145fb1 vfs_mknod+0x161 (0xc5253a80, 0xce15fc60, 0xc1ed, 0x0, 0xc5253a80) kernel .text 0xc0100000 0xc0145e50 0xc0146010 0xc6d11f04 0xc01916aa nfsd_create+0x2ca (0xc6d1fe00, 0xc6d1fa04, 0xc0536ca0, 0x6, 0xc6d1fca4) kernel .text 0xc0100000 0xc01913e0 0xc0191740 0xc6d11f30 0xc019696e nfsd3_proc_mknod+0x18e (0xc6d1fe00, 0xc6d0c014, 0x0, 0x49, 0xb) kernel .text 0xc0100000 0xc01967e0 0xc0196980 0xc6d11f88 0xc0297c16 svc_process+0x2a6 (0xcfdaf560, 0xc6d1fe00, 0xc6d10674, 0xcfdaf560, 0xc6d13fd0) kernel .text 0xc0100000 0xc0297970 0xc0297e80 0xc6d11fc0 0xc018d2db nfsd+0x1fb kernel .text 0xc0100000 0xc018d0e0 0xc018d410 0xc6d11ff4 0xc0107296 kernel_thread+0x26 kernel .text 0xc0100000 0xc0107270 0xc01072a0 -- 辝ref Tufan 辝n 軹-B軩B Sistem Destek Grubu From owner-linux-xfs@oss.sgi.com Fri Oct 11 03:13:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 03:13:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BADOtG012982 for ; Fri, 11 Oct 2002 03:13:25 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA28918; Fri, 11 Oct 2002 05:13:19 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-15.corp.sgi.com [134.15.64.15]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id FAA36316; Fri, 11 Oct 2002 05:13:19 -0500 (CDT) Subject: Re: correct patch was Re: TAKE - make xfs's in memory extents host byte ordered From: Stephen Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021011030912.A1359@wotan.suse.de> References: <200210101909.g9AJ9pd12773@jen.americas.sgi.com> <20021010213259.A23019@wotan.suse.de> <1034296295.1074.28.camel@laptop.americas.sgi.com> <20021011030451.A27822@wotan.suse.de> <20021011030912.A1359@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Oct 2002 05:09:31 -0500 Message-Id: <1034330973.1400.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 20:09, Andi Kleen wrote: > > Last mail had the wrong patch. Here is the correct one that should > actually compile > > > --- linux/include/linux/byteorder/swab.h-o 2001-07-26 22:45:47.000000000 +0200 > +++ linux/include/linux/byteorder/swab.h 2002-10-11 03:03:32.000000000 +0200 > @@ -167,11 +167,11 @@ > } > static __inline__ __u64 __swab64p(__u64 *x) > { > - return __arch__swab64p(x); > + *x = __fswab64(*x); > } > static __inline__ void __swab64s(__u64 *addr) > { > - __arch__swab64s(addr); > + *addr = __fswab64(*addr); > } > #endif /* __BYTEORDER_HAS_U64__ */ > Are you sure that would help? We only call into __swab64() from XFS and, provided builtin_constant_p is doing its stuff this should turn into __fswab64 which will execute this code: __u32 h = x >> 32; __u32 l = x & ((1ULL<<32)-1); return (((__u64)__swab32(l)) << 32) | ((__u64)(__swab32(h))); At least I hope so... Also that change to the pointer version looks wrong, you have a function which is supposed to return a value and no longer does. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 11 03:44:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 03:45:06 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BAittG013897 for ; Fri, 11 Oct 2002 03:44:56 -0700 Received: from fwd10.sul.t-online.de by mailout11.sul.t-online.com with smtp id 17zxHn-0004TQ-04; Fri, 11 Oct 2002 12:44:51 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.250.178]) by fmrl10.sul.t-online.com with esmtp id 17zxHY-0jaGfYC; Fri, 11 Oct 2002 12:44:36 +0200 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9B6quLB003114; Fri, 11 Oct 2002 08:52:56 +0200 Date: Fri, 11 Oct 2002 08:52:56 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: [2.4.18-14SGI_XFS_1.2a1] xfs_inotobp/xfs_force_shutdown Message-ID: <20021011065256.GA2797@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 915 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A 1.2pre kernel (SGI XFS CVS-09/19/02:05 with ACLs, quota, no debug enabled) just produced the following: Oct 11 07:46:40 puariko kernel: xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,12). Returning error.xfs_iunlink_remove: xfs_inotobp() returned an error 22 on ide0(3,12).^I Returning error.xfs_inactive:^Ixfs_ifree() returned an error = 22 on ide0(3,12) Oct 11 07:46:40 puariko kernel: xfs_force_shutdown(ide0(3,12),0x1) called from line 1913 of file xfs_vnodeops.c. Return address = 0xc01d79e0 Oct 11 07:46:40 puariko kernel: I/O Error Detected. Shutting down filesystem: ide0(3,12) Oct 11 07:46:40 puariko kernel: Please umount the filesystem, and rectify the problem(s) o I brought the box into single user mode o umounted the fs o ran xfs_check on it (first attachment) o ran xfs_repair on it (it advised me to mount/umount the fs to recover the journal) o mounted/umounted o reran xfs_check on it (second attachment) o ran xfs_repair on it (third attachment) Is this related to "Hardy I.D." 's similar problems with xfs_force_shutdown or is my HDD dying (I am running smartd, should it had given an error, too)? Thanks, Axel. -- Axel.Thimm@physik.fu-berlin.de --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_check_dev_hda.log" bad format 2 for inode 38416738 type 0 bad format 2 for inode 38416742 type 0 bad format 1 for inode 38416743 type 0 bad format 1 for inode 38416744 type 0 bad format 2 for inode 38416745 type 0 bad format 2 for inode 38416746 type 0 bad format 2 for inode 38416747 type 0 bad format 2 for inode 38416748 type 0 bad format 2 for inode 38416749 type 0 bad format 2 for inode 38416750 type 0 bad format 2 for inode 38416751 type 0 bad format 2 for inode 38416756 type 0 bad format 2 for inode 38416757 type 0 bad format 2 for inode 38416758 type 0 bad format 1 for inode 38416759 type 0 bad format 2 for inode 38416760 type 0 bad format 2 for inode 38416761 type 0 bad format 2 for inode 38416762 type 0 bad format 2 for inode 38416763 type 0 bad format 2 for inode 38416764 type 0 bad format 2 for inode 38416765 type 0 bad format 2 for inode 38416766 type 0 bad format 1 for inode 38416767 type 0 agi unlinked bucket 30 is 777374 in ag 30 (inode=126606494) block 3/44012 type unknown not expected link count mismatch for inode 34179079 (name ?), nlink 3, counted 2 link count mismatch for inode 34179080 (name ?), nlink 3, counted 2 link count mismatch for inode 34179087 (name ?), nlink 7, counted 6 block 9/41707 type unknown not expected block 9/41708 type unknown not expected block 9/41845 type unknown not expected block 9/41870 type unknown not expected block 9/41871 type unknown not expected block 9/41872 type unknown not expected block 9/41873 type unknown not expected block 9/41874 type unknown not expected block 9/41875 type unknown not expected block 9/41876 type unknown not expected block 9/41877 type unknown not expected block 9/41878 type unknown not expected block 9/41879 type unknown not expected block 9/41880 type unknown not expected block 9/41881 type unknown not expected block 9/41882 type unknown not expected block 9/41883 type unknown not expected block 9/41884 type unknown not expected block 9/41885 type unknown not expected block 9/41886 type unknown not expected block 9/41888 type unknown not expected block 9/41889 type unknown not expected block 9/41890 type unknown not expected block 9/41891 type unknown not expected block 9/41892 type unknown not expected block 9/41893 type unknown not expected block 9/41894 type unknown not expected block 9/41895 type unknown not expected block 9/41897 type unknown not expected block 9/41898 type unknown not expected block 9/41899 type unknown not expected block 9/41900 type unknown not expected block 9/41901 type unknown not expected block 9/41902 type unknown not expected block 9/41903 type unknown not expected block 9/41904 type unknown not expected block 9/41905 type unknown not expected block 9/41906 type unknown not expected disconnected inode 38501479, nlink 1 disconnected inode 38501480, nlink 1 disconnected inode 38501481, nlink 1 disconnected inode 38501482, nlink 1 disconnected inode 38501483, nlink 1 disconnected inode 38501484, nlink 1 disconnected inode 38501485, nlink 1 disconnected inode 38501486, nlink 1 disconnected inode 38501487, nlink 1 disconnected inode 38501488, nlink 1 disconnected inode 38501489, nlink 1 disconnected inode 38501490, nlink 1 disconnected inode 38501491, nlink 1 disconnected inode 38501492, nlink 1 disconnected inode 38501493, nlink 1 disconnected inode 38501494, nlink 1 disconnected inode 38501495, nlink 1 disconnected inode 38418272, nlink 1 disconnected inode 38359625, nlink 1 link count mismatch for inode 38416736 (name ?), nlink 0, counted 1 link count mismatch for inode 38416737 (name ?), nlink 0, counted 1 link count mismatch for inode 38416738 (name ?), nlink 0, counted 1 link count mismatch for inode 38416739 (name ?), nlink 0, counted 1 link count mismatch for inode 38416740 (name ?), nlink 0, counted 1 link count mismatch for inode 38416741 (name ?), nlink 0, counted 1 link count mismatch for inode 38416742 (name ?), nlink 0, counted 1 link count mismatch for inode 38416743 (name ?), nlink 0, counted 1 link count mismatch for inode 38416744 (name ?), nlink 0, counted 1 allocated inode 38416745 has 0 link count allocated inode 38416746 has 0 link count link count mismatch for inode 38416747 (name ?), nlink 0, counted 3 allocated inode 38416748 has 0 link count allocated inode 38416749 has 0 link count allocated inode 38416750 has 0 link count allocated inode 38416751 has 0 link count allocated inode 38416752 has 0 link count allocated inode 38416753 has 0 link count allocated inode 38416754 has 0 link count allocated inode 38416755 has 0 link count allocated inode 38416756 has 0 link count link count mismatch for inode 38416757 (name ?), nlink 0, counted 1 link count mismatch for inode 38416758 (name ?), nlink 0, counted 1 link count mismatch for inode 38416759 (name ?), nlink 0, counted 1 allocated inode 38416760 has 0 link count allocated inode 38416761 has 0 link count allocated inode 38416762 has 0 link count allocated inode 38416763 has 0 link count allocated inode 38416764 has 0 link count allocated inode 38416765 has 0 link count allocated inode 38416766 has 0 link count link count mismatch for inode 38416767 (name ?), nlink 0, counted 1 disconnected inode 38477573, nlink 1 disconnected inode 38477574, nlink 1 disconnected inode 38477575, nlink 1 link count mismatch for inode 42532355 (name ?), nlink 3, counted 2 link count mismatch for inode 42536612 (name ?), nlink 6, counted 5 link count mismatch for inode 50494254 (name ?), nlink 2, counted 1 allocated inode 126606494 has 0 link count link count mismatch for inode 169171702 (name ?), nlink 75, counted 73 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_check_dev_hda.log2" bad format 2 for inode 38416738 type 0 bad format 2 for inode 38416742 type 0 bad format 1 for inode 38416743 type 0 bad format 1 for inode 38416744 type 0 bad format 2 for inode 38416745 type 0 bad format 2 for inode 38416746 type 0 bad format 2 for inode 38416747 type 0 bad format 2 for inode 38416748 type 0 bad format 2 for inode 38416749 type 0 bad format 2 for inode 38416750 type 0 bad format 2 for inode 38416751 type 0 bad format 2 for inode 38416756 type 0 bad format 2 for inode 38416757 type 0 bad format 2 for inode 38416758 type 0 bad format 1 for inode 38416759 type 0 bad format 2 for inode 38416760 type 0 bad format 2 for inode 38416761 type 0 bad format 2 for inode 38416762 type 0 bad format 2 for inode 38416763 type 0 bad format 2 for inode 38416764 type 0 bad format 2 for inode 38416765 type 0 bad format 2 for inode 38416766 type 0 bad format 1 for inode 38416767 type 0 link count mismatch for inode 34179079 (name ?), nlink 3, counted 2 link count mismatch for inode 34179080 (name ?), nlink 3, counted 2 link count mismatch for inode 34179087 (name ?), nlink 7, counted 6 block 9/41707 type unknown not expected block 9/41708 type unknown not expected block 9/41845 type unknown not expected block 9/41870 type unknown not expected block 9/41871 type unknown not expected block 9/41872 type unknown not expected block 9/41873 type unknown not expected block 9/41874 type unknown not expected block 9/41875 type unknown not expected block 9/41876 type unknown not expected block 9/41877 type unknown not expected block 9/41878 type unknown not expected block 9/41879 type unknown not expected block 9/41880 type unknown not expected block 9/41881 type unknown not expected block 9/41882 type unknown not expected block 9/41883 type unknown not expected block 9/41884 type unknown not expected block 9/41885 type unknown not expected block 9/41886 type unknown not expected block 9/41888 type unknown not expected block 9/41889 type unknown not expected block 9/41890 type unknown not expected block 9/41891 type unknown not expected block 9/41892 type unknown not expected block 9/41893 type unknown not expected block 9/41894 type unknown not expected block 9/41895 type unknown not expected block 9/41897 type unknown not expected block 9/41898 type unknown not expected block 9/41899 type unknown not expected block 9/41900 type unknown not expected block 9/41901 type unknown not expected block 9/41902 type unknown not expected block 9/41903 type unknown not expected block 9/41904 type unknown not expected block 9/41905 type unknown not expected block 9/41906 type unknown not expected disconnected inode 38501479, nlink 1 disconnected inode 38501480, nlink 1 disconnected inode 38501481, nlink 1 disconnected inode 38501482, nlink 1 disconnected inode 38501483, nlink 1 disconnected inode 38501484, nlink 1 disconnected inode 38501485, nlink 1 disconnected inode 38501486, nlink 1 disconnected inode 38501487, nlink 1 disconnected inode 38501488, nlink 1 disconnected inode 38501489, nlink 1 disconnected inode 38501490, nlink 1 disconnected inode 38501491, nlink 1 disconnected inode 38501492, nlink 1 disconnected inode 38501493, nlink 1 disconnected inode 38501494, nlink 1 disconnected inode 38501495, nlink 1 disconnected inode 38418272, nlink 1 disconnected inode 38359625, nlink 1 link count mismatch for inode 38416736 (name ?), nlink 0, counted 1 link count mismatch for inode 38416737 (name ?), nlink 0, counted 1 link count mismatch for inode 38416738 (name ?), nlink 0, counted 1 link count mismatch for inode 38416739 (name ?), nlink 0, counted 1 link count mismatch for inode 38416740 (name ?), nlink 0, counted 1 link count mismatch for inode 38416741 (name ?), nlink 0, counted 1 link count mismatch for inode 38416742 (name ?), nlink 0, counted 1 link count mismatch for inode 38416743 (name ?), nlink 0, counted 1 link count mismatch for inode 38416744 (name ?), nlink 0, counted 1 allocated inode 38416745 has 0 link count allocated inode 38416746 has 0 link count link count mismatch for inode 38416747 (name ?), nlink 0, counted 3 allocated inode 38416748 has 0 link count allocated inode 38416749 has 0 link count allocated inode 38416750 has 0 link count allocated inode 38416751 has 0 link count allocated inode 38416752 has 0 link count allocated inode 38416753 has 0 link count allocated inode 38416754 has 0 link count allocated inode 38416755 has 0 link count allocated inode 38416756 has 0 link count link count mismatch for inode 38416757 (name ?), nlink 0, counted 1 link count mismatch for inode 38416758 (name ?), nlink 0, counted 1 link count mismatch for inode 38416759 (name ?), nlink 0, counted 1 allocated inode 38416760 has 0 link count allocated inode 38416761 has 0 link count allocated inode 38416762 has 0 link count allocated inode 38416763 has 0 link count allocated inode 38416764 has 0 link count allocated inode 38416765 has 0 link count allocated inode 38416766 has 0 link count link count mismatch for inode 38416767 (name ?), nlink 0, counted 1 disconnected inode 38477573, nlink 1 disconnected inode 38477574, nlink 1 disconnected inode 38477575, nlink 1 link count mismatch for inode 42532355 (name ?), nlink 3, counted 2 link count mismatch for inode 42536612 (name ?), nlink 6, counted 5 link count mismatch for inode 50494254 (name ?), nlink 2, counted 1 link count mismatch for inode 169171702 (name ?), nlink 75, counted 73 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_repair_dev_hda.log" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 bad inode format in inode 38416743 bad inode format in inode 38416759 bad attribute format 0 in inode 38416736, resetting value bad attribute format 0 in inode 38416737, resetting value imap claims a free inode 38416738 is in use, correcting imap and clearing inode cleared inode 38416738 bad attribute format 0 in inode 38416739, resetting value bad attribute format 0 in inode 38416740, resetting value bad attribute format 0 in inode 38416741, resetting value imap claims a free inode 38416742 is in use, correcting imap and clearing inode cleared inode 38416742 bad inode format in inode 38416743 cleared inode 38416743 imap claims a free inode 38416744 is in use, correcting imap and clearing inode cleared inode 38416744 imap claims a free inode 38416745 is in use, correcting imap and clearing inode cleared inode 38416745 imap claims a free inode 38416746 is in use, correcting imap and clearing inode cleared inode 38416746 imap claims a free inode 38416747 is in use, correcting imap and clearing inode cleared inode 38416747 imap claims a free inode 38416748 is in use, correcting imap and clearing inode cleared inode 38416748 imap claims a free inode 38416749 is in use, correcting imap and clearing inode cleared inode 38416749 imap claims a free inode 38416750 is in use, correcting imap and clearing inode cleared inode 38416750 imap claims a free inode 38416751 is in use, correcting imap and clearing inode cleared inode 38416751 bad attribute format 0 in inode 38416752, resetting value bad attribute format 0 in inode 38416753, resetting value bad attribute format 0 in inode 38416754, resetting value bad attribute format 0 in inode 38416755, resetting value imap claims a free inode 38416756 is in use, correcting imap and clearing inode cleared inode 38416756 imap claims a free inode 38416757 is in use, correcting imap and clearing inode cleared inode 38416757 imap claims a free inode 38416758 is in use, correcting imap and clearing inode cleared inode 38416758 bad inode format in inode 38416759 cleared inode 38416759 imap claims a free inode 38416760 is in use, correcting imap and clearing inode cleared inode 38416760 imap claims a free inode 38416761 is in use, correcting imap and clearing inode cleared inode 38416761 imap claims a free inode 38416762 is in use, correcting imap and clearing inode cleared inode 38416762 imap claims a free inode 38416763 is in use, correcting imap and clearing inode cleared inode 38416763 imap claims a free inode 38416764 is in use, correcting imap and clearing inode cleared inode 38416764 imap claims a free inode 38416765 is in use, correcting imap and clearing inode cleared inode 38416765 imap claims a free inode 38416766 is in use, correcting imap and clearing inode cleared inode 38416766 imap claims a free inode 38416767 is in use, correcting imap and clearing inode cleared inode 38416767 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 entry "LC_MESSAGES" in shortform directory 34179079 references free inode 38416743 junking entry "LC_MESSAGES" in directory inode 34179079 entry "LC_MESSAGES" in shortform directory 34179080 references free inode 38416744 junking entry "LC_MESSAGES" in directory inode 34179080 entry "icon-view" in shortform directory 34179087 references free inode 38416767 junking entry "icon-view" in directory inode 34179087 - agno = 9 entry "slrnpull-expire" at block 0 offset 520 in directory inode 38416729 references free inode 38416738 clearing inode number in entry at offset 520... entry "tripwire-check" at block 0 offset 760 in directory inode 38416729 references free inode 38416742 clearing inode number in entry at offset 760... entry "cache" in shortform directory 38418273 references free inode 38416757 junking entry "cache" in directory inode 38418273 - agno = 10 entry "g" in shortform directory 42536612 references free inode 38416758 junking entry "g" in directory inode 42536612 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 entry "ppp" at block 0 offset 3624 in directory inode 169171702 references free inode 38416747 clearing inode number in entry at offset 3624... entry "ups" at block 1 offset 3520 in directory inode 169171702 references free inode 38416759 clearing inode number in entry at offset 3520... - agno = 41 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 rebuilding directory inode 169171702 rebuilding directory inode 38416729 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 38359625, moving to lost+found disconnected inode 38416752, moving to lost+found disconnected inode 38416753, moving to lost+found disconnected inode 38416754, moving to lost+found disconnected inode 38416755, moving to lost+found disconnected inode 38418272, moving to lost+found disconnected inode 38477573, moving to lost+found disconnected inode 38477574, moving to lost+found disconnected inode 38477575, moving to lost+found disconnected inode 38501479, moving to lost+found disconnected inode 38501480, moving to lost+found disconnected inode 38501481, moving to lost+found disconnected inode 38501482, moving to lost+found disconnected inode 38501483, moving to lost+found disconnected inode 38501484, moving to lost+found disconnected inode 38501485, moving to lost+found disconnected inode 38501486, moving to lost+found disconnected inode 38501487, moving to lost+found disconnected inode 38501488, moving to lost+found disconnected inode 38501489, moving to lost+found disconnected inode 38501490, moving to lost+found disconnected inode 38501491, moving to lost+found disconnected inode 38501492, moving to lost+found disconnected inode 38501493, moving to lost+found disconnected inode 38501494, moving to lost+found disconnected inode 38501495, moving to lost+found disconnected dir inode 42532355, moving to lost+found disconnected dir inode 50494254, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 34179079 nlinks from 3 to 2 resetting inode 34179080 nlinks from 3 to 2 resetting inode 34179087 nlinks from 7 to 6 resetting inode 38416736 nlinks from 0 to 1 resetting inode 38416737 nlinks from 0 to 1 resetting inode 38416739 nlinks from 0 to 1 resetting inode 38416740 nlinks from 0 to 1 resetting inode 38416741 nlinks from 0 to 1 resetting inode 42536612 nlinks from 6 to 5 resetting inode 169171702 nlinks from 75 to 73 done --XsQoSWH+UP9D9v3l-- From owner-linux-xfs@oss.sgi.com Fri Oct 11 04:27:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 04:27:14 -0700 (PDT) Received: from hotmail.com (f4.law15.hotmail.com [64.4.23.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BBR9tG015021 for ; Fri, 11 Oct 2002 04:27:09 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Oct 2002 04:27:04 -0700 Received: from 211.110.6.218 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 11 Oct 2002 11:27:04 GMT X-Originating-IP: [211.110.6.218] From: "Seungsoo Lee" To: linux-xfs@oss.sgi.com Subject: can't mount a hard with xfs filesystem. Date: Fri, 11 Oct 2002 20:27:04 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2002 11:27:04.0800 (UTC) FILETIME=[20310600:01C27119] X-archive-position: 916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yiseungsu@hotmail.com Precedence: bulk X-list: linux-xfs please, help me. Yesterday , I got a messege as below. I have also searched the related document. But I can't solve this problem. The hard disk size is 80G byte,and That contains many files . it is used well before, but I can't now. ****** mount failure message*************** #mount -t xfs /dev/hdd1 /mnt/mnt5 mount:wrong fs type, bad option, bad superblock on /dev/hdd1, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) ****** my act after the problem ********************** #xfs_repair -v /dev/hdd1 Phase 1 -find and verify superblock... superblock read failed, offset 0,size 524288, ag 0,rval 0 fatal error --Invalid argument 1) is there any chance to recover this hard disk? 2)if there are, how can I fix this problem? please I'm waiting for your honorable idea? Your tips will be helpful to me. thanks for reading this. Seungsu Yi if you can contact to me directly, my E-mail address: yiseungsu@hotmail.com _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-linux-xfs@oss.sgi.com Fri Oct 11 08:31:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 08:31:27 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BFVMtG025006 for ; Fri, 11 Oct 2002 08:31:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA94648 for ; Fri, 11 Oct 2002 10:31:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA03993 for ; Fri, 11 Oct 2002 10:31:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BFTR502150; Fri, 11 Oct 2002 10:29:27 -0500 Message-Id: <200210111529.g9BFTR502150@jen.americas.sgi.com> Date: Fri, 11 Oct 2002 10:29:27 -0500 Subject: TAKE - fold VOP_STRATEGY into VOP_BMAP To: linux-xfs@oss.sgi.com X-archive-position: 917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Cleanup, no functional changes. merge strategy and bmap calls, they are two aspects of the same operation. Date: Fri Oct 11 08:30:34 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129728a linux/fs/xfs/xfs_vnodeops.c - 1.568 - remove strategy from the vop definitions linux/fs/xfs/linux/xfs_lrw.h - 1.29 - remove strategy prototype linux/fs/xfs/linux/xfs_lrw.c - 1.172 - call strategy out of bmap linux/fs/xfs/linux/xfs_vnode.h - 1.66 - remove VOP_STRATEGY linux/fs/xfs/linux/xfs_aops.c - 1.8 - always call VOP_BMAP, make PBF_WRITE and PBF_FILE_ALLOCATE seperate flags. From owner-linux-xfs@oss.sgi.com Fri Oct 11 09:16:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 09:16:27 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGGKtG025798 for ; Fri, 11 Oct 2002 09:16:22 -0700 Received: from rose.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by lips.thebarn.com (8.12.6/8.12.4) with ESMTP id g9BGGJ0d013634; Fri, 11 Oct 2002 11:16:19 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: XFS 1.1 unlink() weirdness From: Russell Cattelan To: Mihai RUSU Cc: Linux XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Oct 2002 11:16:14 -0500 Message-Id: <1034352980.1162.12.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 22:26, Mihai RUSU wrote: > Hi > > We run a 2.4.9-31SGI_XFS_1.1 based server. While the free space got bellow > 85% we observed that almost every operation on our XFS partition was > slower. This should be somewhat normal when having FSs with small free > space. The weird thing is if I unlink() a file which has been created a > long time ago (when the FS had 60% disk free) it deletes it instantly > (even if having > 800 MB size). But if I delete a 50mb file created 3 days > ago it takes almost a minute ?! Is that normal ? :) If your filesytem has gotten fragmented over time then it is likely your 50mb file is spread across a lot of extents, removing a file with a large number of extents takes longer than a file with only a few extents. You can look at the number of extent for a particular file with the xfs_bmap command. > > Thanks > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > From owner-linux-xfs@oss.sgi.com Fri Oct 11 09:17:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 09:18:00 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGHvtG026055 for ; Fri, 11 Oct 2002 09:17:58 -0700 Received: from rose.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by lips.thebarn.com (8.12.6/8.12.4) with ESMTP id g9BGBv0d013579; Fri, 11 Oct 2002 11:12:06 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: XFS 1.2Pre and nfs problem From: Russell Cattelan To: =?ISO-8859-1?Q?=DEeref?= Tufan =?ISO-8859-1?Q?=DEen?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021011124432.253ca55a.tufan@itu.edu.tr> References: <20021011124432.253ca55a.tufan@itu.edu.tr> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Oct 2002 11:11:52 -0500 Message-Id: <1034352726.1162.7.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9BGHwtG026056 X-archive-position: 919 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs So couple quick things first if you could submit a bug report via bugzilla. http://oss.sgi.com/bugzilla/ We have decided to give a bug tracking system a try. Hopefully this will help with tracking and keep things from falling through the cracks. Second do you have any more info as to what is going on over the nfs mount? it might help us reproduce the error locally. On Fri, 2002-10-11 at 04:44, 脼eref Tufan 脼en wrote: > I have a nfs server running XFS. I have problems with 2.4.19+xfs 1.2pre kernels. Nfsd processes are getting stuck at state D. > > I have kdb and got a back trace of one the stuck nfsd processes. > System : RH 7.1 > NFS-Utils : Was Red Hat original , upgraded to 1.0.1 the same happens. > Using LVM and qlogic 2100 HBA. XFS volumes are accessible through HBA.. > > First NFSD got stuck at D state > ---------------------------------------- > [root@lnxsrv2 /root]# ps -eo pid,stat,args,wchan | grep nfs > 1237 SW [nfsd] svc_recv > 1238 SW [nfsd] svc_recv > 1239 SW [nfsd] svc_recv > 1240 SW [nfsd] svc_recv > 1241 SW [nfsd] svc_recv > 1242 SW [nfsd] svc_recv > 1243 SW [nfsd] svc_recv > 1244 SW [nfsd] svc_recv > 1245 SW [nfsd] svc_recv > 1246 SW [nfsd] svc_recv > 1247 SW [nfsd] svc_recv > 1248 SW [nfsd] svc_recv > 1249 SW [nfsd] svc_recv > 1250 SW [nfsd] svc_recv > 1251 SW [nfsd] svc_recv > 1252 DW [nfsd] down > 2321 S grep nfs pipe_wait > > ALL NFSD processes got stuck at D state > ---------------------------------------------------- > [root@lnxsrv2 /root]# ps -eo pid,stat,args,wchan | grep nfs > 1237 DW [nfsd] exp_readlock > 1238 DW [nfsd] exp_readlock > 1239 DW [nfsd] exp_readlock > 1240 DW [nfsd] exp_readlock > 1241 DW [nfsd] exp_readlock > 1242 DW [nfsd] exp_readlock > 1243 DW [nfsd] exp_readlock > 1244 DW [nfsd] exp_readlock > 1245 DW [nfsd] exp_readlock > 1246 DW [nfsd] exp_readlock > 1247 DW [nfsd] exp_readlock > 1248 DW [nfsd] exp_readlock > 1249 DW [nfsd] exp_readlock > 1250 DW [nfsd] exp_readlock > 1251 DW [nfsd] exp_readlock > 1252 DW [nfsd] down > 3072 S grep nfs pipe_wait > > > > KDB back trace > ------------------------------------ > 0xc6d11b1c 0xc0107826 __down+0x68 > kernel .text 0xc0100000 0xc0107710 0xc0107890 > 0xc6d11b38 0xc01079d4 __down_failed+0x8 (0xc71acecc, 0xc01fc0c2, 0xc71acec0, 0x15, 0x400) > kernel .text 0xc0100000 0xc01079cc 0xc01079d8 > 0xc6d11b48 0xc01fe453 .text.lock.page_buf_locking+0xf > kernel .text 0xc0100000 0xc01fe444 0xc01fe460 > 0xc6d11b48 0xc01fe2e9 pagebuf_lock+0x39 (0xc71acec0, 0x15, 0x400, 0x1) > kernel .text 0xc0100000 0xc01fe2b0 0xc01fe2f0 > 0xc6d11b50 0xc01fc0c2 _pagebuf_find+0x192 (0xc12cf3c0, 0x800002, 0x0, 0x200, 0x22205) > kernel .text 0xc0100000 0xc01fbf30 0xc01fc110 > 0xc6d11b74 0xc01fc1a8 pagebuf_get+0x68 (0xc12cf3c0, 0x800002, 0x0, 0x1, 0x22205) > kernel .text 0xc0100000 0xc01fc140 0xc01fc260 > 0xc6d11ba4 0xc01f1ffb xfs_trans_read_buf+0x1eb (0xc84ed400, 0xc2c60b68, 0xc12cf3c0, 0x800002, 0x0) > kernel .text 0xc0100000 0xc01f1e10 0xc01f2140 > 0xc6d11bcc 0xc01db0d3 xfs_ialloc_read_agi+0x43 (0xc84ed400, 0xc2c60b68, 0x1, 0xc6d11c2c, 0xc6d11c2c) > kernel .text 0xc0100000 0xc01db090 0xc01db160 > 0xc6d11c04 0xc01d9f32 xfs_ialloc_ag_select+0x232 (0xc2c60b68, 0x111d8ee, 0x0, 0xc1ed, 0x1) > kernel .text 0xc0100000 0xc01d9d00 0xc01d9fc0 > 0xc6d11c44 0xc01da01c xfs_dialloc+0x5c (0xc2c60b68, 0x111d8ee, 0x0, 0xc1ed, 0x1) > kernel .text 0xc0100000 0xc01f3100 0xc01f3380 > 0xc6d11db4 0xc01f7540 xfs_create+0x2c0 (0xc4e1d828, 0xce15fc60, 0xc6d11e5c, 0xc6d11e58, 0x0) > kernel .text 0xc0100000 0xc01f7280 0xc01f7790 > 0xc6d11e40 0xc0201eca linvfs_mknod+0x11a (0xc5253a80, 0xce15fc60, 0xc1ed, 0x0, 0x0) > kernel .text 0xc0100000 0xc0201db0 0xc0202020 > 0xc6d11ee0 0xc0145fb1 vfs_mknod+0x161 (0xc5253a80, 0xce15fc60, 0xc1ed, 0x0, 0xc5253a80) > kernel .text 0xc0100000 0xc0145e50 0xc0146010 > 0xc6d11f04 0xc01916aa nfsd_create+0x2ca (0xc6d1fe00, 0xc6d1fa04, 0xc0536ca0, 0x6, 0xc6d1fca4) > kernel .text 0xc0100000 0xc01913e0 0xc0191740 > 0xc6d11f30 0xc019696e nfsd3_proc_mknod+0x18e (0xc6d1fe00, 0xc6d0c014, 0x0, 0x49, 0xb) > kernel .text 0xc0100000 0xc01967e0 0xc0196980 > 0xc6d11f88 0xc0297c16 svc_process+0x2a6 (0xcfdaf560, 0xc6d1fe00, 0xc6d10674, 0xcfdaf560, 0xc6d13fd0) > kernel .text 0xc0100000 0xc0297970 0xc0297e80 > 0xc6d11fc0 0xc018d2db nfsd+0x1fb > kernel .text 0xc0100000 0xc018d0e0 0xc018d410 > 0xc6d11ff4 0xc0107296 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0107270 0xc01072a0 > > > > -- > 艦eref Tufan 艦en > 陌T脺-B陌DB > Sistem Destek Grubu > > From owner-linux-xfs@oss.sgi.com Fri Oct 11 09:24:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 09:24:55 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGOotG026751 for ; Fri, 11 Oct 2002 09:24:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA82300 for ; Fri, 11 Oct 2002 11:24:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA20529 for ; Fri, 11 Oct 2002 11:24:45 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BGMtB03017; Fri, 11 Oct 2002 11:22:55 -0500 Subject: That last take message which removed VOP_STRATEGY From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Oct 2002 11:22:55 -0500 Message-Id: <1034353375.2972.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs After updating a kernel to include this, please make sure you remove all the .o files in xfs and rebuild completely. There is a dependency bug which means a lot of things which need rebuilding do not get rebuilt. End result is you oops if you do not do this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 11 09:25:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 09:25:10 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGP7tG026862 for ; Fri, 11 Oct 2002 09:25:08 -0700 Received: from rose.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by lips.thebarn.com (8.12.6/8.12.4) with ESMTP id g9BGOt0d013711; Fri, 11 Oct 2002 11:24:55 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: can't mount a hard with xfs filesystem. From: Russell Cattelan To: Seungsoo Lee Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Oct 2002 11:24:50 -0500 Message-Id: <1034353496.1157.17.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-11 at 06:27, Seungsoo Lee wrote: > > > please, help me. > > Yesterday , I got a messege as below. I have also searched the related > document. > But I can't solve this problem. > > The hard disk size is 80G byte,and That contains many files . > it is used well before, but I can't now. > > > > ****** mount failure message*************** > #mount -t xfs /dev/hdd1 /mnt/mnt5 > mount:wrong fs type, bad option, bad superblock on /dev/hdd1, > or too many mounted file systems > (could this be the IDE device where you in fact use > ide-scsi so that sr0 or sda or so is needed?) > > ****** my act after the problem ********************** > #xfs_repair -v /dev/hdd1 > Phase 1 -find and verify superblock... > superblock read failed, offset 0,size 524288, ag 0,rval 0 > > fatal error --Invalid argument > did you recently add any disks to your system? it's possible you are looking at the wrong disk and/or partition xfs_repair should find any valid superblocks on the partition if there is any. try this quick test dd if=/dev/hdd1 bs=512 count=1 |hexdump you should seem output similar to this: 0000000 4658 4253 0000 0010 0000 0000 1f00 00ac 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 8807 6a43 d635 bd4c e4aa d477 fa58 e5bc 0000030 0000 0000 1000 0400 0000 0000 0000 8000 0000040 0000 0000 0000 8100 0000 0000 0000 8200 0000050 0000 1000 0300 80f5 0000 0800 0000 0000 0000060 0000 b004 9420 0002 0001 1000 002f 0000 0000070 0000 0000 0000 0000 090c 0408 0012 1900 0000080 0000 0000 0200 4018 0000 0000 0000 6d01 0000090 0000 0000 1400 4506 0000 0000 0000 0000 00000a0 0000 0000 0000 0000 0000 0000 0000 0000 00000b0 0000 0000 0000 0200 0000 0000 0000 0000 00000c0 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 The 4658 4253 is XFSB and the magic number for an xfs file system. > > > 1) is there any chance to recover this hard disk? > 2)if there are, how can I fix this problem? > > please I'm waiting for your honorable idea? Your tips will be helpful to me. > > thanks for reading this. > > > Seungsu Yi > > if you can contact to me directly, > my E-mail address: yiseungsu@hotmail.com > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-linux-xfs@oss.sgi.com Fri Oct 11 09:56:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 09:56:16 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGuCtG028673 for ; Fri, 11 Oct 2002 09:56:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA21050 for ; Fri, 11 Oct 2002 11:56:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA35747 for ; Fri, 11 Oct 2002 11:56:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BGsGo05849; Fri, 11 Oct 2002 11:54:16 -0500 Message-Id: <200210111654.g9BGsGo05849@jen.americas.sgi.com> Date: Fri, 11 Oct 2002 11:54:16 -0500 Subject: TAKE - make a few more transactions async To: linux-xfs@oss.sgi.com X-archive-position: 922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs fix some off by one errors in the busy list search code used during space allocation. The errors were benevolent, we flushed the log more than we needed to. Date: Fri Oct 11 09:53:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129745a linux/fs/xfs/xfs_alloc.c - 1.154 - fix alloc busy list off by one errors, and simplify the bounds check code. From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:02:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:02:11 -0700 (PDT) Received: from hotmail.com (f136.law15.hotmail.com [64.4.23.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BH27tG029132 for ; Fri, 11 Oct 2002 10:02:08 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Oct 2002 10:02:01 -0700 Received: from 211.110.6.218 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 11 Oct 2002 17:02:01 GMT X-Originating-IP: [211.110.6.218] From: "Seungsoo Lee" To: cattelan@thebarn.com Cc: linux-xfs@oss.sgi.com Subject: re: return for thank and more question Date: Sat, 12 Oct 2002 02:02:01 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2002 17:02:01.0536 (UTC) FILETIME=[EAC79400:01C27147] X-archive-position: 923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yiseungsu@hotmail.com Precedence: bulk X-list: linux-xfs Dear, Russell Cattelan I really appreciate your graceful message. As you teach me, I do it firstly. But I can't see what you give. ****************************************** # dd if=/dev/hdd1 bs=512 count=1 |hexdump 0+0 records in 0+0 records out ***************************************** I don't know what those means exactly. I guess this situation seems to be desperate. I am wondering if I take your precious time away. By the way , can I repair this? Thanks thanks you over millions of times. be happy. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:18:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:18:06 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BHI0tG030139 for ; Fri, 11 Oct 2002 10:18:02 -0700 Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 1803Q4-00089o-00; Fri, 11 Oct 2002 18:17:48 +0100 Message-ID: <3DA707BC.F6F56592@moving-picture.com> Date: Fri, 11 Oct 2002 18:17:48 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Log corruption? References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> <3DA19858.75C9E674@moving-picture.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs It's just happened on one of my workstations - at bootup I get (2.4.18-xfs [XFS 1.1] kernel): XFS mounting filesystem sd(8,2) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) xfs_inotobp: xfs_imap() returned error 22 on sd(8,2). Returning error. xfs_iunlink_remove: xfs_inotobp() returned error 22 on sd(8,2). Returning error xfs_inactive:: xfs_ifree() returned error = 22 on sd(8,2) xfs_force_shutdown(sd(8,2),0x1) called from line 1962 of file xfs_vnodeops.c Return address = 0xc01cd7a2 I/O Error Detected. Shutting down filesystem: sd(8,2) Please umount the filesystem, and rectify the problem(s) Ending XFS recovery on filesystem: sd(8,2) (dev: 8/2) pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 Freeing unused kernel memory: 252k freed Kernel panic: No init found. Try passing init= option to kernel If I boot off floppy/CD in rescue mode and try to mount the root partition by hand I get (2.4.7-10SGI_XFS_PR1BOOT kernel): XFS mounting filesystem sd(8,17) Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) XFS mounting filesystem sd(8,2) Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) Unable to handle kernel NULL pointer dereference at virtual address 00000152 printing eip: fc93faf2 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c0226d84 edx: fc96e2c0 esi: f6aa17e4 edi: f6a6ec00 ebp: 00000000 esp: f7fd58b4 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 102, stackpage=f7fd5000) Stack: 41d20700 00000000 f6a6ec16 41d20700 fc94cbd0 f6a6ec00 00000000 41d20700 00000000 00000000 f7fd5924 00000000 00000000 c21c2b60 00000000 00000000 00000000 f6a6ed64 f6a6ed64 41d20700 00000000 c21c2b60 f7fd5924 0187d281 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 6b Running xfs_repair -L 'fixes' the problem. James Pearson James Pearson wrote: > > The sequence of events is: > > Machine locks up - probably related to some Xwindows/application problem > (we use the Nvidia drivers) > > Machine is reset > > Kernel boots > > Fails to mount the root (XFS) file system - either with an oops of some > error telling us the file system is corrupt etc. > > Attempts to reset again produce same results above. > > Booting in rescue mode, running 'xfs_repair -L' and rebooting "fixes" > the problem. xfs_repair finds some lost file and puts them in lost+found > - these are usually files from /tmp or /var/tmp. > > This doesn't happen every time a machine locks up, but it occurs may be > once a week or so on one or another of our 60 or so workstations. > > James Pearson > > Stephen Lord wrote: > > > > On Mon, 2002-10-07 at 07:45, James Pearson wrote: > > > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > > > 1.1 kernel - every now and then a (different) machine will crash/hang > > > and fail to boot with a kernel oops and/or with XFS errors when it tries > > > to mount the root file system. > > > > > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > > > on the root partition. The root file system is them mountable and the > > > machine reboots OK. > > > > > > I don't have exact error messages (don't have time to write down the > > > exact errors, as the priority is to get the machine up and running ...) > > > > > > Is this a known problem? If it isn't, I'll attempt to get more > > > information when it happens again. > > > > > > James Pearson > > > > > > > Actually, a change just went into the cvs tree this weekend which might > > be related to this, there is some zeroing of part of the log which is > > always supposed to happen during mount. For a readonly mount this was > > not happening - and the root is mounted this way. Should the machine > > be shutdown and rebooted very shortly after this there is a possibility > > of the second mount getting confused by the log contents. > > > > Is there any way this could be what is happening? Is this happening > > on the second of two boots which are close together? > > > > Currently there is no way to get this code except from a cvs kernel, > > we just put out some images of the first alpha of xfs 1.2, the next > > spin of these should include this fix (hint hint Eric). > > > > Steve From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:33:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:33:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BHXWtG000836 for ; Fri, 11 Oct 2002 10:33:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA60144; Fri, 11 Oct 2002 12:33:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA30030; Fri, 11 Oct 2002 12:33:26 -0500 (CDT) Subject: Re: Log corruption? From: Eric Sandeen To: James Pearson Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: <3DA707BC.F6F56592@moving-picture.com> References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> <3DA19858.75C9E674@moving-picture.com> <3DA707BC.F6F56592@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Oct 2002 12:30:48 -0500 Message-Id: <1034357448.13979.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 925 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs James - I think Steve previously pointed out that there was a recent fix that may address this... We'll get a new 1.2 prerelease spin out there soon which will contain it. It would probably also be fairly easy to get you a patch for 1.1 if you'd prefer. -Eric On Fri, 2002-10-11 at 12:17, James Pearson wrote: > It's just happened on one of my workstations - at bootup I get > (2.4.18-xfs [XFS 1.1] kernel): > > XFS mounting filesystem sd(8,2) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > xfs_inotobp: xfs_imap() returned error 22 on sd(8,2). Returning error. > xfs_iunlink_remove: xfs_inotobp() returned error 22 on sd(8,2). > Returning error > xfs_inactive:: xfs_ifree() returned error = 22 on sd(8,2) > xfs_force_shutdown(sd(8,2),0x1) called from line 1962 of file > xfs_vnodeops.c Return address = 0xc01cd7a2 > I/O Error Detected. Shutting down filesystem: sd(8,2) > Please umount the filesystem, and rectify the problem(s) > Ending XFS recovery on filesystem: sd(8,2) (dev: 8/2) > pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 > Freeing unused kernel memory: 252k freed > Kernel panic: No init found. Try passing init= option to kernel > > > If I boot off floppy/CD in rescue mode and try to mount the root > partition by hand I get (2.4.7-10SGI_XFS_PR1BOOT kernel): > > XFS mounting filesystem sd(8,17) > Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) > Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) > XFS mounting filesystem sd(8,2) > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > Unable to handle kernel NULL pointer dereference at virtual address > 00000152 > printing eip: > fc93faf2 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] > EFLAGS: 00010246 > eax: 00000000 ebx: ffffffe8 ecx: c0226d84 edx: fc96e2c0 > esi: f6aa17e4 edi: f6a6ec00 ebp: 00000000 esp: f7fd58b4 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 102, stackpage=f7fd5000) > Stack: 41d20700 00000000 f6a6ec16 41d20700 fc94cbd0 f6a6ec00 00000000 > 41d20700 > 00000000 00000000 f7fd5924 00000000 00000000 c21c2b60 00000000 > 00000000 > 00000000 f6a6ed64 f6a6ed64 41d20700 00000000 c21c2b60 f7fd5924 > 0187d281 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] > > Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 6b > > Running xfs_repair -L 'fixes' the problem. > > James Pearson > > James Pearson wrote: > > > > The sequence of events is: > > > > Machine locks up - probably related to some Xwindows/application problem > > (we use the Nvidia drivers) > > > > Machine is reset > > > > Kernel boots > > > > Fails to mount the root (XFS) file system - either with an oops of some > > error telling us the file system is corrupt etc. > > > > Attempts to reset again produce same results above. > > > > Booting in rescue mode, running 'xfs_repair -L' and rebooting "fixes" > > the problem. xfs_repair finds some lost file and puts them in lost+found > > - these are usually files from /tmp or /var/tmp. > > > > This doesn't happen every time a machine locks up, but it occurs may be > > once a week or so on one or another of our 60 or so workstations. > > > > James Pearson > > > > Stephen Lord wrote: > > > > > > On Mon, 2002-10-07 at 07:45, James Pearson wrote: > > > > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > > > > 1.1 kernel - every now and then a (different) machine will crash/hang > > > > and fail to boot with a kernel oops and/or with XFS errors when it tries > > > > to mount the root file system. > > > > > > > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > > > > on the root partition. The root file system is them mountable and the > > > > machine reboots OK. > > > > > > > > I don't have exact error messages (don't have time to write down the > > > > exact errors, as the priority is to get the machine up and running ...) > > > > > > > > Is this a known problem? If it isn't, I'll attempt to get more > > > > information when it happens again. > > > > > > > > James Pearson > > > > > > > > > > Actually, a change just went into the cvs tree this weekend which might > > > be related to this, there is some zeroing of part of the log which is > > > always supposed to happen during mount. For a readonly mount this was > > > not happening - and the root is mounted this way. Should the machine > > > be shutdown and rebooted very shortly after this there is a possibility > > > of the second mount getting confused by the log contents. > > > > > > Is there any way this could be what is happening? Is this happening > > > on the second of two boots which are close together? > > > > > > Currently there is no way to get this code except from a cvs kernel, > > > we just put out some images of the first alpha of xfs 1.2, the next > > > spin of these should include this fix (hint hint Eric). > > > > > > Steve > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:44:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:44:33 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BHiStG001388 for ; Fri, 11 Oct 2002 10:44:30 -0700 Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 1803pe-0008Kw-00; Fri, 11 Oct 2002 18:44:14 +0100 Message-ID: <3DA70DEE.190877FF@moving-picture.com> Date: Fri, 11 Oct 2002 18:44:14 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Log corruption? References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> <3DA19858.75C9E674@moving-picture.com> <3DA707BC.F6F56592@moving-picture.com> <1034357448.13979.9.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs If a patch against XFS 1.1 is easy to do, then that'll be fine for the moment... Thanks James Pearson Eric Sandeen wrote: > > James - I think Steve previously pointed out that there was a recent fix > that may address this... We'll get a new 1.2 prerelease spin out there > soon which will contain it. It would probably also be fairly easy to > get you a patch for 1.1 if you'd prefer. > > -Eric > > On Fri, 2002-10-11 at 12:17, James Pearson wrote: > > It's just happened on one of my workstations - at bootup I get > > (2.4.18-xfs [XFS 1.1] kernel): > > > > XFS mounting filesystem sd(8,2) > > XFS: WARNING: recovery required on readonly filesystem. > > XFS: write access will be enabled during mount. > > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > xfs_inotobp: xfs_imap() returned error 22 on sd(8,2). Returning error. > > xfs_iunlink_remove: xfs_inotobp() returned error 22 on sd(8,2). > > Returning error > > xfs_inactive:: xfs_ifree() returned error = 22 on sd(8,2) > > xfs_force_shutdown(sd(8,2),0x1) called from line 1962 of file > > xfs_vnodeops.c Return address = 0xc01cd7a2 > > I/O Error Detected. Shutting down filesystem: sd(8,2) > > Please umount the filesystem, and rectify the problem(s) > > Ending XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 > > Freeing unused kernel memory: 252k freed > > Kernel panic: No init found. Try passing init= option to kernel > > > > > > If I boot off floppy/CD in rescue mode and try to mount the root > > partition by hand I get (2.4.7-10SGI_XFS_PR1BOOT kernel): > > > > XFS mounting filesystem sd(8,17) > > Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) > > Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) > > XFS mounting filesystem sd(8,2) > > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000152 > > printing eip: > > fc93faf2 > > *pde = 00000000 > > Oops: 0000 > > CPU: 0 > > EIP: 0010:[] > > EFLAGS: 00010246 > > eax: 00000000 ebx: ffffffe8 ecx: c0226d84 edx: fc96e2c0 > > esi: f6aa17e4 edi: f6a6ec00 ebp: 00000000 esp: f7fd58b4 > > ds: 0018 es: 0018 ss: 0018 > > Process mount (pid: 102, stackpage=f7fd5000) > > Stack: 41d20700 00000000 f6a6ec16 41d20700 fc94cbd0 f6a6ec00 00000000 > > 41d20700 > > 00000000 00000000 f7fd5924 00000000 00000000 c21c2b60 00000000 > > 00000000 > > 00000000 f6a6ed64 f6a6ed64 41d20700 00000000 c21c2b60 f7fd5924 > > 0187d281 > > Call Trace: [] [] [] [] > > [] > > [] [] [] [] [] > > [] > > [] [] [] [] [] > > [] > > [] [] [] [] [] > > [] > > [] [] [] [] [] > > [] > > [] [] > > > > Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 6b > > > > Running xfs_repair -L 'fixes' the problem. > > > > James Pearson > > > > James Pearson wrote: > > > > > > The sequence of events is: > > > > > > Machine locks up - probably related to some Xwindows/application problem > > > (we use the Nvidia drivers) > > > > > > Machine is reset > > > > > > Kernel boots > > > > > > Fails to mount the root (XFS) file system - either with an oops of some > > > error telling us the file system is corrupt etc. > > > > > > Attempts to reset again produce same results above. > > > > > > Booting in rescue mode, running 'xfs_repair -L' and rebooting "fixes" > > > the problem. xfs_repair finds some lost file and puts them in lost+found > > > - these are usually files from /tmp or /var/tmp. > > > > > > This doesn't happen every time a machine locks up, but it occurs may be > > > once a week or so on one or another of our 60 or so workstations. > > > > > > James Pearson > > > > > > Stephen Lord wrote: > > > > > > > > On Mon, 2002-10-07 at 07:45, James Pearson wrote: > > > > > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > > > > > 1.1 kernel - every now and then a (different) machine will crash/hang > > > > > and fail to boot with a kernel oops and/or with XFS errors when it tries > > > > > to mount the root file system. > > > > > > > > > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > > > > > on the root partition. The root file system is them mountable and the > > > > > machine reboots OK. > > > > > > > > > > I don't have exact error messages (don't have time to write down the > > > > > exact errors, as the priority is to get the machine up and running ...) > > > > > > > > > > Is this a known problem? If it isn't, I'll attempt to get more > > > > > information when it happens again. > > > > > > > > > > James Pearson > > > > > > > > > > > > > Actually, a change just went into the cvs tree this weekend which might > > > > be related to this, there is some zeroing of part of the log which is > > > > always supposed to happen during mount. For a readonly mount this was > > > > not happening - and the root is mounted this way. Should the machine > > > > be shutdown and rebooted very shortly after this there is a possibility > > > > of the second mount getting confused by the log contents. > > > > > > > > Is there any way this could be what is happening? Is this happening > > > > on the second of two boots which are close together? > > > > > > > > Currently there is no way to get this code except from a cvs kernel, > > > > we just put out some images of the first alpha of xfs 1.2, the next > > > > spin of these should include this fix (hint hint Eric). > > > > > > > > Steve > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:45:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:46:01 -0700 (PDT) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BHjqtG001469 for ; Fri, 11 Oct 2002 10:45:58 -0700 Received: from rose.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by lips.thebarn.com (8.12.6/8.12.4) with ESMTP id g9BHjl0d014715; Fri, 11 Oct 2002 12:45:50 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: re: return for thank and more question From: Russell Cattelan To: Seungsoo Lee Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Oct 2002 12:45:42 -0500 Message-Id: <1034358350.1157.20.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-11 at 12:02, Seungsoo Lee wrote: > > > Dear, Russell Cattelan > > > I really appreciate your graceful message. > As you teach me, I do it firstly. > But I can't see what you give. > > ****************************************** > > # dd if=/dev/hdd1 bs=512 count=1 |hexdump > 0+0 records in > 0+0 records out > hmm that is a bad sign. I looks like your drive had died. Check /var/log/messages to see if any drive/controller errors are being reported. > ***************************************** > > > I don't know what those means exactly. > > I guess this situation seems to be desperate. > I am wondering if I take your precious time away. > > By the way , can I repair this? > > Thanks thanks you over millions of times. > > be happy. > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx From owner-linux-xfs@oss.sgi.com Fri Oct 11 10:51:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 10:51:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BHp7tG001828 for ; Fri, 11 Oct 2002 10:51:08 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA88702; Fri, 11 Oct 2002 12:51:01 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA21687; Fri, 11 Oct 2002 12:51:00 -0500 (CDT) Subject: Re: Log corruption? From: Eric Sandeen To: James Pearson Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: <3DA70DEE.190877FF@moving-picture.com> References: <3DA181D2.B78A9C41@moving-picture.com> <1033996292.1053.32.camel@laptop.americas.sgi.com> <3DA19858.75C9E674@moving-picture.com> <3DA707BC.F6F56592@moving-picture.com> <1034357448.13979.9.camel@stout.americas.sgi.com> <3DA70DEE.190877FF@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Oct 2002 12:48:22 -0500 Message-Id: <1034358502.13979.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs How about a pseudo-patch, since I don't actually have 1.1 source handy at the moment... look in xlog_find_tail, in linux/fs/xfs/xfs_log_recover.c Change the bit that says: if (!readonly) error = xlog_clear_stale_blocks(log, tail_lsn); to if (!is_read_only(log->l_mp->m_logdev_targp->pbr_kdev)) { error = xlog_clear_stale_blocks(log, tail_lsn); } Note that this won't fix your filesystems where you've already seen corruption, but it will hopefully prevent corruption in the future. -Eric On Fri, 2002-10-11 at 12:44, James Pearson wrote: > If a patch against XFS 1.1 is easy to do, then that'll be fine for the > moment... > > Thanks > > James Pearson > > Eric Sandeen wrote: > > > > James - I think Steve previously pointed out that there was a recent fix > > that may address this... We'll get a new 1.2 prerelease spin out there > > soon which will contain it. It would probably also be fairly easy to > > get you a patch for 1.1 if you'd prefer. > > > > -Eric > > > > On Fri, 2002-10-11 at 12:17, James Pearson wrote: > > > It's just happened on one of my workstations - at bootup I get > > > (2.4.18-xfs [XFS 1.1] kernel): > > > > > > XFS mounting filesystem sd(8,2) > > > XFS: WARNING: recovery required on readonly filesystem. > > > XFS: write access will be enabled during mount. > > > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > > xfs_inotobp: xfs_imap() returned error 22 on sd(8,2). Returning error. > > > xfs_iunlink_remove: xfs_inotobp() returned error 22 on sd(8,2). > > > Returning error > > > xfs_inactive:: xfs_ifree() returned error = 22 on sd(8,2) > > > xfs_force_shutdown(sd(8,2),0x1) called from line 1962 of file > > > xfs_vnodeops.c Return address = 0xc01cd7a2 > > > I/O Error Detected. Shutting down filesystem: sd(8,2) > > > Please umount the filesystem, and rectify the problem(s) > > > Ending XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > > pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 > > > Freeing unused kernel memory: 252k freed > > > Kernel panic: No init found. Try passing init= option to kernel > > > > > > > > > If I boot off floppy/CD in rescue mode and try to mount the root > > > partition by hand I get (2.4.7-10SGI_XFS_PR1BOOT kernel): > > > > > > XFS mounting filesystem sd(8,17) > > > Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) > > > Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) > > > XFS mounting filesystem sd(8,2) > > > Starting XFS recovery on filesystem: sd(8,2) (dev: 8/2) > > > Unable to handle kernel NULL pointer dereference at virtual address > > > 00000152 > > > printing eip: > > > fc93faf2 > > > *pde = 00000000 > > > Oops: 0000 > > > CPU: 0 > > > EIP: 0010:[] > > > EFLAGS: 00010246 > > > eax: 00000000 ebx: ffffffe8 ecx: c0226d84 edx: fc96e2c0 > > > esi: f6aa17e4 edi: f6a6ec00 ebp: 00000000 esp: f7fd58b4 > > > ds: 0018 es: 0018 ss: 0018 > > > Process mount (pid: 102, stackpage=f7fd5000) > > > Stack: 41d20700 00000000 f6a6ec16 41d20700 fc94cbd0 f6a6ec00 00000000 > > > 41d20700 > > > 00000000 00000000 f7fd5924 00000000 00000000 c21c2b60 00000000 > > > 00000000 > > > 00000000 f6a6ed64 f6a6ed64 41d20700 00000000 c21c2b60 f7fd5924 > > > 0187d281 > > > Call Trace: [] [] [] [] > > > [] > > > [] [] [] [] [] > > > [] > > > [] [] [] [] [] > > > [] > > > [] [] [] [] [] > > > [] > > > [] [] [] [] [] > > > [] > > > [] [] > > > > > > Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 6b > > > > > > Running xfs_repair -L 'fixes' the problem. > > > > > > James Pearson > > > > > > James Pearson wrote: > > > > > > > > The sequence of events is: > > > > > > > > Machine locks up - probably related to some Xwindows/application problem > > > > (we use the Nvidia drivers) > > > > > > > > Machine is reset > > > > > > > > Kernel boots > > > > > > > > Fails to mount the root (XFS) file system - either with an oops of some > > > > error telling us the file system is corrupt etc. > > > > > > > > Attempts to reset again produce same results above. > > > > > > > > Booting in rescue mode, running 'xfs_repair -L' and rebooting "fixes" > > > > the problem. xfs_repair finds some lost file and puts them in lost+found > > > > - these are usually files from /tmp or /var/tmp. > > > > > > > > This doesn't happen every time a machine locks up, but it occurs may be > > > > once a week or so on one or another of our 60 or so workstations. > > > > > > > > James Pearson > > > > > > > > Stephen Lord wrote: > > > > > > > > > > On Mon, 2002-10-07 at 07:45, James Pearson wrote: > > > > > > We have a number of workstations running RedHat 7.2 with a 2.4.18 XFS > > > > > > 1.1 kernel - every now and then a (different) machine will crash/hang > > > > > > and fail to boot with a kernel oops and/or with XFS errors when it tries > > > > > > to mount the root file system. > > > > > > > > > > > > The fix is to boot from floppy/CD in rescue mode and run 'xfs_repair -L' > > > > > > on the root partition. The root file system is them mountable and the > > > > > > machine reboots OK. > > > > > > > > > > > > I don't have exact error messages (don't have time to write down the > > > > > > exact errors, as the priority is to get the machine up and running ...) > > > > > > > > > > > > Is this a known problem? If it isn't, I'll attempt to get more > > > > > > information when it happens again. > > > > > > > > > > > > James Pearson > > > > > > > > > > > > > > > > Actually, a change just went into the cvs tree this weekend which might > > > > > be related to this, there is some zeroing of part of the log which is > > > > > always supposed to happen during mount. For a readonly mount this was > > > > > not happening - and the root is mounted this way. Should the machine > > > > > be shutdown and rebooted very shortly after this there is a possibility > > > > > of the second mount getting confused by the log contents. > > > > > > > > > > Is there any way this could be what is happening? Is this happening > > > > > on the second of two boots which are close together? > > > > > > > > > > Currently there is no way to get this code except from a cvs kernel, > > > > > we just put out some images of the first alpha of xfs 1.2, the next > > > > > spin of these should include this fix (hint hint Eric). > > > > > > > > > > Steve > > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. 651-683-3102 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 11:31:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 11:31:03 -0700 (PDT) Received: from mta3.sucs.soton.ac.uk (mta3.sucs.soton.ac.uk [152.78.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BIUwtG003243 for ; Fri, 11 Oct 2002 11:30:59 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by mta3.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9BIU1Cf007784; Fri, 11 Oct 2002 19:30:46 +0100 Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id OAA31857; Fri, 11 Oct 2002 14:32:25 +0100 From: X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f To: Stephen Lord Subject: Re: Xfs_force_shutdown on recent XFS CVS Message-ID: <1034343145.3da6d2e954ec8@webmail.soton.ac.uk> Date: Fri, 11 Oct 2002 14:32:25 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk References: <1034270623.1400.162.camel@jen.americas.sgi.com> <1034289105.3da5ffd17e21c@webmail.soton.ac.uk> <1034295549.1073.10.camel@laptop.americas.sgi.com> In-Reply-To: <1034295549.1073.10.camel@laptop.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.179.201.63 X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-1.5, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME, DOUBLE_CAPSWORD, WEIRD_PORT, DATE_IN_PAST_03_06) X-archive-position: 929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Quoting Stephen Lord : > On Thu, 2002-10-10 at 17:31, I.D.Hardy@soton.ac.uk wrote: > > > > On 10 Oct 2002 12:23:43 -0500: Steve Lord Wrote: > > > > > > > > Ian, did you run xfs_check and repair before mounting the fs or > > > after? You should mount again after reboot, then run check. > > > The in memory corruption error means it failed an internal check > > > on a memory buffer, not that it had found bad data on the disk. > > > > > > If you have the check/repair output, please send it, but there is > > > no real way to tell if the issues in it were from running the > > > commands with a dirty log or not. > > > > > > We really need to improve that particular trace message, there > > > are 80 some places it could have originated. Lets see if we > > > can do something about that. > > > > > > Steve > > > > > > > > > > Steve, thanks as always for your reply. Yes, the server was rebooted, > and the > > filesystem mounted and unmounted prior to running xfs_check/repair. > Also, > > a 'xfs_fsr' was run when we upgraded the kernel (on an idle system), > the system > > was then rebooted and 'xfs_check' ran on the filesystem (clean) before > the > > server was but back into service (and therefore prior to the 2 > filesystem > > shutdowns); I can therefore be confident that any FS corruption > occurred while > > running the new (Wed 8th) XFS CVS kernel. > > > > Here's the output from the xfs_check/xfs_repair runs following the > first > > filesystem shutdown (xfs_clean was clean following the 2nd > shutdown). > > > > ..... (sorry I missed capturing the top of this xfs_check session, > though > > I think this was near the start). > > Hmm, you have ascii data on top of inodes by the look of it. So this > looks like a rogue write. You have 64 inodes here which look like they > were completely overwritten. Working out where this came from is key > here. I am not aware of anything which changed recently which might > relate to this. > > Steve > > Steve, may be coincidence, but reverted back to a slightly earlier 2.4.19 XFS- CVS (above shutdown/xfs_repair output from 'SGI XFS CVS-10/08/02:05 with quota, no debug enabled' reverted to 'SGI XFS CVS-09/15/02:17 with quota, no debug enabled) and the server seems to have reverted to kernel panics/crashes. Have just got the following Ooops dump from it: Oct 11 13:01:21 blue01 kernel: kernel BUG at slab.c:1263! Oct 11 13:01:21 blue01 kernel: invalid operand: 0000 Oct 11 13:01:21 blue01 kernel: CPU: 0 Oct 11 13:01:21 blue01 kernel: EIP: 0010:[] Not tainted Oct 11 13:01:21 blue01 kernel: EOct 11 13:01:21 blue01 kernel: kernel BUG at slab.c:1263! Oct 11 13:01:21 blue01 kernel: invalid operand: 0000 Oct 11 13:01:21 blue01 kernel: CPU: 0 Oct 11 13:01:21 blue01 kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 FLAGS: 00010013 Oct 11 13:01:21 blue01 kernel: eax: c8cf364b ebx: c8cf3628 ecx: 00000020 edx: c8cf362c Oct 11 13:01:21 blue01 kernel: esi: 00020c00 edi: 00000000 ebp: c1c0f060 esp: f7eaddf0 Oct 11 13:01:21 blue01 kernel: ds: 0018 es: 0018 ss: 0018 Oct 11 13:01:21 blue01 kernel: Process pagebuf_io_CPU0 (pid: 9, stackpage=f7ead000) Oct 11 13:01:21 blue01 kernel: Stack: c8cf362c 00000020 00000000 00000040 c1c0f060 00000000 000000f0 c1c0f060 Oct 11 13:01:21 blue01 kernel: c0133192 c1c0f060 f7edf000 000000f0 00000246 c56e3cf4 00000000 0002cd1a Oct 11 13:01:21 blue01 kernel: 00000246 d051146c 00000000 d05114cc 00000001 c01e4f64 0000000c 000000f0 Oct 11 13:01:21 blue01 kernel: Call Trace: [] [] [] [] [] Oct 11 13:01:21 blue01 kernel: [] [] [] [] [] [] Oct 11 13:01:21 blue01 kernel: [] [] Oct 11 13:01:21 blue01 kernel: Oct 11 13:01:21 blue01 kernel: Code: 0f 0b ef 04 a0 54 2b c0 81 e6 00 04 00 00 74 37 b8 a5 c2 0f Oct 11 13:01:21 blue01 kernel: EFLAGS: 00010013 Oct 11 13:01:21 blue01 kernel: eax: c8cf364b ebx: c8cf3628 ecx: 00000020 edx: c8cf362c Oct 11 13:01:21 blue01 kernel: esi: 00020c00 edi: 00000000 ebp: c1c0f060 esp: f7eaddf0 Oct 11 13:01:21 blue01 kernel: ds: 0018 es: 0018 ss: 0018 Oct 11 13:01:21 blue01 kernel: Process pagebuf_io_CPU0 (pid: 9, stackpage=f7ead000) Oct 11 13:01:21 blue01 kernel: Stack: c8cf362c 00000020 00000000 00000040 c1c0f060 00000000 000000f0 c1c0f060 Oct 11 13:01:21 blue01 kernel: c0133192 c1c0f060 f7edf000 000000f0 00000246 c56e3cf4 00000000 0002cd1a Oct 11 13:01:21 blue01 kernel: 00000246 d051146c 00000000 d05114cc 00000001 c01e4f64 0000000c 000000f0 Oct 11 13:01:21 blue01 kernel: Call Trace: [] [] [] [] [] Oct 11 13:01:21 blue01 kernel: [] [] [] [] [] [] Oct 11 13:01:21 blue01 kernel: [] [] Oct 11 13:01:21 blue01 kernel: Code: 0f 0b ef 04 a0 54 2b c0 81 e6 00 04 00 00 74 37 b8 a5 c2 0f >>EIP; c0132c26 <===== Trace; c0133192 Trace; c01e4f64 <_pagebuf_page_io+304/450> Trace; c01d973e Trace; c01e51dc <_page_buf_page_apply+12c/140> Trace; c01e564c <_pagebuf_segment_apply+ac/110> Trace; c01e52d8 Trace; c01cce44 Trace; c01cd6c0 Trace; c01ced10 Trace; c011f25c <__run_task_queue+5c/70> Trace; c01e58e4 Trace; c0107296 Trace; c01e5770 Code; c0132c26 00000000 <_EIP>: Code; c0132c26 <===== 0: 0f 0b ud2a <===== Code; c0132c28 2: ef out %eax,(%dx) Code; c0132c28 3: 04 a0 add $0xa0,%al Code; c0132c2a 5: 54 push %esp Code; c0132c2c 6: 2b c0 sub %eax,%eax Code; c0132c2e 8: 81 e6 00 04 00 00 and $0x400,%esi Code; c0132c34 e: 74 37 je 47 <_EIP+0x47> c0132c6c Code; c0132c36 10: b8 a5 c2 0f 00 mov $0xfc2a5,%eax Though this is different to previous/recent crashes from the same kernel that have been more of the form: Sep 25 20:36:50 blue01 kernel: kernel BUG at slab.c:1439! Sep 25 20:36:50 blue01 kernel: invalid operand: 0000 Sep 25 20:36:50 blue01 kernel: CPU: 1 Sep 25 20:36:50 blue01 kernel: EIP: 0010:[] Not tainted Sep 25 20:36:50 blue01 kernel: ESep 25 20:36:50 blue01 kernel: kernel BUG at slab.c:1439! Sep 25 20:36:50 blue01 kernel: invalid operand: 0000 Sep 25 20:36:50 blue01 kernel: CPU: 1 Sep 25 20:36:50 blue01 kernel: EIP: 0010:[] Not tainted FLAGS: 00010016 Sep 25 20:36:50 blue01 kernel: eax: 5a2cf071 ebx: 00a59840 ecx: f7edec10 edx: c1c0f060 Sep 25 20:36:50 blue01 kernel: esi: f732c000 edi: f732cf5c ebp: f732cee8 esp: f7eddf48 Sep 25 20:36:50 blue01 kernel: ds: 0018 es: 0018 ss: 0018 Sep 25 20:36:50 blue01 kernel: Process kswapd (pid: 5, stackpage=f7edd000) Sep 25 20:36:50 blue01 kernel: Stack: 00008842 00000002 f7edec10 f7edec00 00000000 00000002 00000000 00000000 Sep 25 20:36:50 blue01 kernel: 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 Sep 25 20:36:50 blue01 kernel: 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Sep 25 20:36:50 blue01 kernel: Call Trace: [] [] [] [] [] Sep 25 20:36:50 blue01 kernel: [] [] [] Sep 25 20:36:50 blue01 kernel: Sep 25 20:36:50 blue01 kernel: Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 Sep 25 20:36:50 blue01 kernel: EFLAGS: 00010016 Sep 25 20:36:50 blue01 kernel: eax: 5a2cf071 ebx: 00a59840 ecx: f7edec10 edx: c1c0f060 Sep 25 20:36:50 blue01 kernel: esi: f732c000 edi: f732cf5c ebp: f732cee8 esp: f7eddf48 Sep 25 20:36:50 blue01 kernel: ds: 0018 es: 0018 ss: 0018 Sep 25 20:36:50 blue01 kernel: Process kswapd (pid: 5, stackpage=f7edd000) Sep 25 20:36:50 blue01 kernel: Stack: 00008842 00000002 f7edec10 f7edec00 00000000 00000002 00000000 00000000 Sep 25 20:36:50 blue01 kernel: 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 Sep 25 20:36:50 blue01 kernel: 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Sep 25 20:36:50 blue01 kernel: Call Trace: [] [] [] [] [] Sep 25 20:36:50 blue01 kernel: [] [] [] Sep 25 20:36:50 blue01 kernel: Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 >>EIP; c0133a64 <===== Trace; c0134e58 Trace; c0134f0c Trace; c0134fb0 Trace; c0135026 Trace; c013515c Trace; c0105000 <_stext+0/0> Trace; c0107296 Trace; c01350c0 Code; c0133a64 00000000 <_EIP>: Code; c0133a64 <===== 0: 0f 0b ud2a <===== Code; c0133a66 2: 9f lahf Code; c0133a66 3: 05 a0 54 2b c0 add $0xc02b54a0,%eax Code; c0133a6c 8: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0133a70 c: 89 ea mov %ebp,%edx Code; c0133a72 e: 8b 48 18 mov 0x18(%eax),%ecx Code; c0133a74 11: b8 71 f0 00 00 mov $0xf071,%eax Regards and thanks Ian Hardy Research Services Information Systems Services Southampton University From owner-linux-xfs@oss.sgi.com Fri Oct 11 12:26:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 12:26:12 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BJQ8tG015606 for ; Fri, 11 Oct 2002 12:26:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA13252 for ; Fri, 11 Oct 2002 14:26:02 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA92654 for ; Fri, 11 Oct 2002 14:26:02 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BJNN817651; Fri, 11 Oct 2002 14:23:23 -0500 Message-Id: <200210111923.g9BJNN817651@stout.americas.sgi.com> Date: Fri, 11 Oct 2002 14:23:23 -0500 Subject: TAKE - Clean up xfs' log message printing X-archive-position: 930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Clean up xfs' log message printing o map all CE_* error levels to matching KERN_* error levels o remove extra newlines from end of error strings, cmn_err adds this for us o remove the "xdprintk" definition, those are KERN_DEBUG messages now o call BUG on any CE_PANIC error messages Date: Fri Oct 11 12:22:58 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129771a linux/fs/xfs/xfs_log.c - 1.256 linux/fs/xfs/xfs_rw.c - 1.367 linux/fs/xfs/xfs_dir.c - 1.143 linux/fs/xfs/xfs_log_recover.c - 1.246 linux/fs/xfs/xfs_vfsops.c - 1.389 linux/fs/xfs/xfs_iget.c - 1.175 linux/fs/xfs/xfs_dir_leaf.c - 1.105 linux/fs/xfs/xfs_qm.c - 1.88 linux/fs/xfs/xfs_error.c - 1.35 linux/fs/xfs/xfs_fsops.c - 1.87 linux/fs/xfs/xfs_trans_buf.c - 1.105 - Remove extra newline from end of cmn_error messages linux/fs/xfs/support/debug.c - 1.11 - Map all CE_* levels to KERN_* printk levels Remove xdprintk definition, we use CE_DEBUG/KERN_DEBUG now BUG() in xfs_icmn_err if CE_PANIC is specified From owner-linux-xfs@oss.sgi.com Fri Oct 11 12:56:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 12:56:19 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BJuFtG017170 for ; Fri, 11 Oct 2002 12:56:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA34264 for ; Fri, 11 Oct 2002 14:56:04 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA30944 for ; Fri, 11 Oct 2002 14:56:04 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BJrPM21766; Fri, 11 Oct 2002 14:53:25 -0500 Message-Id: <200210111953.g9BJrPM21766@stout.americas.sgi.com> Date: Fri, 11 Oct 2002 14:53:25 -0500 Subject: TAKE - More XFS debug-related fixes X-archive-position: 931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs More XFS debug-related fixes Date: Fri Oct 11 12:55:34 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129773a linux/fs/xfs/xfsidbg.c - 1.206 - add xalmtrc kdb command to dump XFS alloc mount-point trace fix pagebuf tracing for "external" traces from xfs_buftrace fix perag command: - don't try to print uninitialized perag lists - don't print busy entries with length 0 linux/fs/xfs/xfs_alloc.c - 1.155 - Fix C syntax in xfs_alloc_trace_modagf() (debug alloc tracing) linux/fs/xfs/linux/xfs_globals.c - 1.37 - export xfs_bmbt_disk_get_all for xfsidbg module From owner-linux-xfs@oss.sgi.com Fri Oct 11 13:42:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 13:42:16 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BKgDtG019257 for ; Fri, 11 Oct 2002 13:42:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA31428 for ; Fri, 11 Oct 2002 15:42:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA55656; Fri, 11 Oct 2002 15:42:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BKeFq30898; Fri, 11 Oct 2002 15:40:15 -0500 Message-Id: <200210112040.g9BKeFq30898@jen.americas.sgi.com> Date: Fri, 11 Oct 2002 15:40:15 -0500 Subject: TAKE - fix some log hang and possible corruption cases To: linux-xfs@oss.sgi.com X-archive-position: 932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Remember that problem 'the shell will make the xfs fs locked' last week, well this fixes it. There was one fairly recent bug in here (last few months) and one ancient bug which looks like it has been there from day one. fix a couple of nasty log problems. When a transaction crosses multiple iclogs, the async transaction code needs to force the log up until the last iclog. We need to record this lsn in the transaction so we can do a log flush on it. Secondly, there was a sleep/wakeup pair between flushing the log and log write completions which was a) incorrect, and b) no longer needed. This could result in early wakeups of threads waiting for log flushes. Date: Fri Oct 11 13:39:00 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:129778a linux/fs/xfs/xfsidbg.c - 1.207 - dump t_commit_lsn when dumping a transaction. linux/fs/xfs/xfs_log.c - 1.257 - remove an sv_signal and an sv_wait on the ic_forcesema which could lead to early wakeups. linux/fs/xfs/xfs_trans.c - 1.135 - record the commit lsn of a transaction into t_commit_lsn during xfs_trans_commit. linux/fs/xfs/xfs_trans.h - 1.114 - Add t_commit_lsn to the transaction structure linux/fs/xfs/xfs_alloc.c - 1.156 - use t_commit_lsn rather than t_lsn when forcing the log before reusing recently freed space. From owner-linux-xfs@oss.sgi.com Fri Oct 11 13:44:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 13:44:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BKiatG019358 for ; Fri, 11 Oct 2002 13:44:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA11444; Fri, 11 Oct 2002 15:44:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA86559; Fri, 11 Oct 2002 15:44:29 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9BKgbK31325; Fri, 11 Oct 2002 15:42:37 -0500 Subject: Re: the shell will make the xfs fs locked From: Steve Lord To: tom wang Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021001092416.74643.qmail@web15204.mail.bjs.yahoo.com> References: <20021001092416.74643.qmail@web15204.mail.bjs.yahoo.com> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 Date: 11 Oct 2002 15:42:37 -0500 Message-Id: <1034368957.2184.52.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9BKibtG019365 X-archive-position: 933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-10-01 at 04:24, tom wang wrote: > xfs-developers: > when I run the shell program as following on a xfs > FS, the process will locked. I just checked some code into cvs which should fix this. Steve > > #!/bin/sh > for((i=0;i<300000;i++)); do > truncate /mnt/current/a $(($i*8192)); > cat /tmp/4kfile >> /mnt/current/a > done > /tmp/4kfile is a 4096-sized file > xfs FS mounted at /mnt/current > the truncate program: > > #include > #include > #include > > int main(int argc, char *argv[]) > { > long long length = 0; > > if( argc < 2 || argc > 3 ){ > printf("Usage: truncate filename [length]\n"); > return -1; > } > > if( argv[2] ) > length = atoll(argv[2]); > > if( truncate64( argv[1], length ) ){ > perror("truncate failed"); > return -1; > } > return 0; > } > > > _________________________________________________________ > Do You Yahoo!? > "鍙戠煭淇¤耽鎵嬫満,蹇潵鍙傚姞闆呰檸宸ㄦ槦绉!" > http://cn.ent.yahoo.com/star/midautumn/index.html > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Oct 11 14:10:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 14:10:31 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BLAHtG020401 for ; Fri, 11 Oct 2002 14:10:18 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60798; Fri, 11 Oct 2002 16:10:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA32131; Fri, 11 Oct 2002 16:10:11 -0500 (CDT) Subject: Re: 1.2 PreRelease avaliable From: Eric Sandeen To: Axel Thimm Cc: Russell Cattelan , linux-xfs@oss.sgi.com In-Reply-To: <20021010192226.GA10689@bonzo.nirvana> References: <1033780525.2804.41.camel@funky> <20021010192226.GA10689@bonzo.nirvana> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Oct 2002 16:07:32 -0500 Message-Id: <1034370452.14692.30.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 14:22, Axel Thimm wrote: > Bugs: > - The installer will not work if you try to install "custom->everything". > After having completed 268 of 1468 packages (754MB of 4691MB) the installer > chokes on anaconda: Hi Axel - thanks for the report. I can duplicate this, but so far I have no idea what the problem might be... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 14:12:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 14:12:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BLCBtG020555 for ; Fri, 11 Oct 2002 14:12:13 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA10484; Fri, 11 Oct 2002 16:12:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA18511; Fri, 11 Oct 2002 16:12:05 -0500 (CDT) Subject: Re: [2.4.18-14SGI_XFS_1.2a1] root xfs filesystem executable bits bug comeback? From: Eric Sandeen To: Axel Thimm Cc: linux-xfs@oss.sgi.com, David Greaves In-Reply-To: <20021011010713.GA4254@bonzo.nirvana> References: <20021011010713.GA4254@bonzo.nirvana> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Oct 2002 16:09:25 -0500 Message-Id: <1034370565.14233.33.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-10 at 20:07, Axel Thimm wrote: > The bug fixed in > > http://marc.theaimsgroup.com/?l=linux-xfs&m=103001217021455&w=2 > > seems to have come back. An XFS root mounted partition returns always true on > all files with "test -x". Non-root mounted XFS partitions are OK. I'll look at this one, since I fixed it last time... Are you running this on a Red Hat 8.0 system? Also, by "root-mounted" you mean the root filesystem, I guess? (i.e. "/"?) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 14:16:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 14:16:26 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BLGLtG021023 for ; Fri, 11 Oct 2002 14:16:23 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA49948; Fri, 11 Oct 2002 16:16:11 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA78290; Fri, 11 Oct 2002 16:16:10 -0500 (CDT) Subject: re: return for thank and more question From: Eric Sandeen To: Russell Cattelan Cc: Seungsoo Lee , linux-xfs@oss.sgi.com In-Reply-To: <1034358350.1157.20.camel@rose.americas.sgi.com> References: <1034358350.1157.20.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Oct 2002 16:13:30 -0500 Message-Id: <1034370811.14692.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-10-11 at 12:45, Russell Cattelan wrote: > hmm that is a bad sign. > I looks like your drive had died. > Check /var/log/messages to see if any drive/controller errors > are being reported. Yep, it looks like any I/O to that drive is failing... same thing from xfs_repair: #xfs_repair -v /dev/hdd1 Phase 1 -find and verify superblock... superblock read failed, offset 0,size 524288, ag 0,rval 0 i.e. it's not saying that the superblock was bad, it's saying that it cannot read any data from the disk. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Oct 11 14:15:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 14:15:56 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BLFptG020949 for ; Fri, 11 Oct 2002 14:15:52 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA01140; Fri, 11 Oct 2002 16:15:40 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18078F-0001yo-00; Fri, 11 Oct 2002 16:15:39 -0500 Date: Fri, 11 Oct 2002 16:15:39 -0500 From: Nathan Straz To: Axel Thimm Cc: Chris Wedgwood , linux-xfs@oss.sgi.com, David Greaves Subject: Re: [2.4.18-14SGI_XFS_1.2a1] root xfs filesystem executable bits bug comeback? Message-ID: <20021011211538.GA27574@sgi.com> Mail-Followup-To: Axel Thimm , Chris Wedgwood , linux-xfs@oss.sgi.com, David Greaves References: <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> <20021011020437.GA1144622@down.physik.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011020437.GA1144622@down.physik.fu-berlin.de> User-Agent: Mutt/1.4i X-archive-position: 936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Oct 11, 2002 at 04:04:37AM +0200, Axel Thimm wrote: > On Thu, Oct 10, 2002 at 06:40:47PM -0700, Chris Wedgwood wrote: > > On Fri, Oct 11, 2002 at 03:07:13AM +0200, Axel Thimm wrote: > > > > An XFS root mounted partition returns always true on all files > > with "test -x". Non-root mounted XFS partitions are OK. > > > > What kernel version(s)? > > The one mentioned in the subject, which is the prerelease version for > SGI_XFS_1.2. I don't see this bug with the version in the subject. [root@tarpon tmp]# df -Th . Filesystem Type Size Used Avail Use% Mounted on /dev/sda6 xfs 3.6G 909M 2.7G 25% / [root@tarpon tmp]# uname -r 2.4.18-14SGI_XFS_1.2a1 [root@tarpon tmp]# touch newfile [root@tarpon tmp]# chmod -x newfile [root@tarpon tmp]# test -x newfile && echo xxx [root@tarpon tmp]# chmod +x newfile [root@tarpon tmp]# test -x newfile && echo xxx xxx [root@tarpon tmp]# rpm -q bash bash-2.05b-5 Can you double check your kernel version and bash version? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Oct 11 15:19:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 15:19:19 -0700 (PDT) Received: from cpw.math.columbia.edu (root@cpw.math.columbia.edu [128.59.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BMJGtG023372 for ; Fri, 11 Oct 2002 15:19:17 -0700 Received: from cpw.math.columbia.edu (atici@localhost [127.0.0.1]) by cpw.math.columbia.edu (8.12.6/8.12.6) with ESMTP id g9BMJERU031703 for ; Fri, 11 Oct 2002 18:19:14 -0400 Received: from localhost (atici@localhost) by cpw.math.columbia.edu (8.12.6/8.12.6/Submit) with ESMTP id g9BMJENW031700 for ; Fri, 11 Oct 2002 18:19:14 -0400 Date: Fri, 11 Oct 2002 18:19:14 -0400 (EDT) From: Alp ATICI To: linux-xfs@oss.sgi.com Subject: Work Items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.20 (www . roaringpenguin . com / mimedefang) X-archive-position: 938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: atici@cpw.math.columbia.edu Precedence: bulk X-list: linux-xfs Hi , I was checking out the "work items" under SGI XFS site, and it hasn't been updated for a long time. Now that 2.5.42 addressed 2 TB limit, would XFS have 64 bit inodes (as it normally has AFAIK on IRIX)? What about the other items that appear as "code complete in CVS"? Are they merged with 2.5 kernel? Thanks, Alp From owner-linux-xfs@oss.sgi.com Fri Oct 11 15:25:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 15:25:49 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BMPktG023841 for ; Fri, 11 Oct 2002 15:25:47 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id <43VH85XQ>; Fri, 11 Oct 2002 15:26:36 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F233@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-xfs@oss.sgi.com'" Cc: "'linux-lvm@sistina.com'" Subject: OOPS in free_pages_ok, caused by locked page Date: Fri, 11 Oct 2002 15:26:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dale.stephenson@quantum.com Precedence: bulk X-list: linux-xfs Using CVS XFS from back in june (2.4.18), using some LVM and extended permission patches, but no patches of the memory system. The processing oopsing was an lvcreate, but lvcreate doesn't use mmap as far as I know. At the time the oops occurred I had one regular LVM volume and was creating the 121st snapshot of it. I've seen the same oops under similar conditions twice (lots of volumes), once with a cgi program and once with a userspace daemon. All had the same backtrace as this one pulled from kdb: kdb> bt EBP EIP Function(args) 0xce835efc 0xc0128573 __free_pages_ok+0x53 kernel .text 0xc0100000 0xc0128520 0xc0128704 0xce835f04 0xc0128c0a __free_pages+0x1e (0xc180e980) kernel .text 0xc0100000 0xc0128bec 0xc0128c10 0xce835f10 0xc0129085 free_page_and_swap_cache+0x35 (0xc180e980, 0x2e5000) kernel .text 0xc0100000 0xc0129050 0xc012908c 0xce835f20 0xc011e04c __free_pte+0x3c (0x203a666f, 0xcf9e8390, 0xcfa85254, 0x40\179000, 0xd29f8014) kernel .text 0xc0100000 0xc011e010 0xc011e054 0xce835f60 0xc011e3e0 zap_page_range+0x158 (0xcfa85254, 0x40179000, 0x196c000, \0xcfa85254, 0xce834000) kernel .text 0xc0100000 0xc011e288 0xc011e488 0xce835f88 0xc01207ab exit_mmap+0xbb (0xcfa85254, 0xcfa85254) kernel .text 0xc0100000 0xc01206f0 0xc0120808 0xce835f98 0xc0111018 mmput+0x3c (0xcfa85254, 0xce834000, 0x40175900, 0x0) kernel .text 0xc0100000 0xc0110fdc 0xc0111038 0xce835fb0 0xc0114f0b do_exit+0x7f (0x0, 0xbffffcf8) kernel .text 0xc0100000 0xc0114e8c 0xc0115050 0xce835fbc 0xc0115078 sys_wait4 (0x0, 0x1000, 0x4017763c, 0x40175900, 0x0) kernel .text 0xc0100000 0xc0115078 0xc011541c 0xc0106edb system_call+0x33 kernel .text 0xc0100000 0xc0106ea8 0xc0106ee0 kdb> page 0xc180e980 struct page at 0xc180e980 next 0xc0365220 prev 0xc0365220 addr space 0x00000000 index 0 (offset 0x0) count 0 flags PG_locked PG_dirty virtual 0xe03a6000 buffers 0x00000000 Clearly, the BUG() call was called by a locked page being freed. I looked around the users of __free_pages(), and most of them seem to unlock the page before making that call [uniprocessor system, so page_cache_release() becomes __free_pages()]. However, free_page_and_swap_cache() assumes the page is unlocked (see the function below). Can anyone help me out? Thanks, Dale Stephenson steph@snapserver.com free_page_and_swap_cache() follows below: /* * Perform a free_page(), also freeing any swap cache associated with * this page if it is the last user of the page. Can not do a lock_page, * as we are holding the page_table_lock spinlock. */ void free_page_and_swap_cache(struct page *page) { /* * If we are the only user, then try to free up the swap cache. * * Its ok to check for PageSwapCache without the page lock * here because we are going to recheck again inside * exclusive_swap_page() _with_ the lock. * - Marcelo */ if (PageSwapCache(page) && !TryLockPage(page)) { remove_exclusive_swap_page(page); UnlockPage(page); } page_cache_release(page); } From owner-linux-xfs@oss.sgi.com Fri Oct 11 15:34:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 15:34:59 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BMYutG024364 for ; Fri, 11 Oct 2002 15:34:57 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id <43VH85YK>; Fri, 11 Oct 2002 15:35:47 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F234@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-xfs@oss.sgi.com'" Subject: memmap in kdb -- how many free pages Date: Fri, 11 Oct 2002 15:35:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dale.stephenson@quantum.com Precedence: bulk X-list: linux-xfs Using the 'memmap' command in kdb, I see that there are 0x3434 0-count pages. As I understand it, these pages should be free for use. Looking at the zone_t structures for the only pg_data_t structure (referenced by pgdat_list), I see 0x98 free pages in the DMA zone, and 0x120 free pages in the Normal zone. (There is no HIGHMEM zone on this box.) So where are all the other free pages hidden? Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Fri Oct 11 17:51:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Oct 2002 17:51:18 -0700 (PDT) Received: from mail.nigol.net.ng (mail.nigol.net.ng [212.96.29.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9C0pDtG027043 for ; Fri, 11 Oct 2002 17:51:15 -0700 Received: from boston ([216.252.176.117]) by mail.nigol.net.ng (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44314U100L100S0) with SMTP id CED536 for ; Sat, 12 Oct 2002 01:48:55 +0100 To: "'linux-xfs@oss.sgi.com'" From: werkenbijdeotto1@37.com Subject: AWARD NOTIFICATION Date: Sat, 12 Oct 2002 01:50:39 +0100 Message-Id: <37541.076844791667200.337296@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: werkenbijdeotto1@37.com Precedence: bulk X-list: linux-xfs WERKEN BIJ DE LOTTO, 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: WBL/67-B773524441 ATTN: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 12TH OCTOBER. 2002, of winners of the WERKEN BIJ DE LOTTO/ INTERNATIONAL PROGRAMS held on 19TH MAY 2002. You / your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$1,500,000.00 in cash credited to file REF NO. REF: WBL/67-B773524441. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To begin your claim, please contact your claims officer immediately: JANSEN DAVIS FOREIGN SERVICE MANAGER, EUROLITE BV, PHONE:31-619676795 FAX: 31 205241590 EMAIL:eurolitebv1@theocffice.net For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than OCTOBER 20 th, 2002. After this date, all funds will be returned as unclaimed. All correspondences to Mr. Jansen Davis,either by fax or email, should have this email sent along with it and also, your email address to which this email is sent, should be clearly and boldly written in your response. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WERKEN BIJ DE LOTTO. www.werken-bij-delotto.net N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply this mail. From owner-linux-xfs@oss.sgi.com Sat Oct 12 04:10:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 04:10:58 -0700 (PDT) Received: from atlas.cc.itu.edu.tr (atlas.cc.itu.edu.tr [160.75.2.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CBAftG026703 for ; Sat, 12 Oct 2002 04:10:48 -0700 Received: from aontws4044.cc.itu.edu.tr (AONTWS4044.cc.itu.edu.tr [160.75.5.44]) by atlas.cc.itu.edu.tr (8.11.6/8.11.2) with SMTP id g9CB9Pp11069; Sat, 12 Oct 2002 14:09:30 +0300 Date: Sat, 12 Oct 2002 14:03:49 +0300 From: 辝ref Tufan 辝n To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2Pre and nfs problem Message-Id: <20021012140349.3c28bcc9.tufan@itu.edu.tr> In-Reply-To: <1034352726.1162.7.camel@rose.americas.sgi.com> References: <20021011124432.253ca55a.tufan@itu.edu.tr> <1034352726.1162.7.camel@rose.americas.sgi.com> Organization: ITU-CC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-redhat-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 X-MIME-Autoconverted: from 8bit to quoted-printable by atlas.cc.itu.edu.tr id g9CB9Pp11069 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9CBArtG026705 X-archive-position: 942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tufan@itu.edu.tr Precedence: bulk X-list: linux-xfs On 11 Oct 2002 11:11:52 -0500 Russell Cattelan wrote: > So couple quick things first if you could submit a bug report via > bugzilla. > http://oss.sgi.com/bugzilla/ > We have decided to give a bug tracking system a try. > Hopefully this will help with tracking and keep things from > falling through the cracks. > Done... http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 > Second do you have any more info as to what is going on over the nfs > mount? it might help us reproduce the error locally. > > No idea. Students home directories are accessible through the nfs server.. Ligth load actually. > -- 辝ref Tufan 辝n 軹-B軩B Sistem Destek Grubu From owner-linux-xfs@oss.sgi.com Sat Oct 12 05:56:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 05:56:45 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CCugtG029341 for ; Sat, 12 Oct 2002 05:56:43 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 180Lov-0004N4-00; Sat, 12 Oct 2002 13:56:41 +0100 Date: Sat, 12 Oct 2002 13:56:41 +0100 From: Christoph Hellwig To: Alp ATICI Cc: linux-xfs@oss.sgi.com Subject: Re: Work Items Message-ID: <20021012135641.B16453@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from atici@cpw.math.columbia.edu on Fri, Oct 11, 2002 at 06:19:14PM -0400 X-archive-position: 943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Oct 11, 2002 at 06:19:14PM -0400, Alp ATICI wrote: > Hi , > > I was checking out the "work items" under SGI XFS site, and > it hasn't been updated for a long time. Now that 2.5.42 addressed > 2 TB limit, would XFS have 64 bit inodes XFS does have 64bit inodes, Linux VFS doesn't. > IRIX)? What about the other items that appear as "code complete in CVS"? > Are they merged with 2.5 kernel? Yes. From owner-linux-xfs@oss.sgi.com Sat Oct 12 08:31:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 08:31:05 -0700 (PDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CFV0tG005020 for ; Sat, 12 Oct 2002 08:31:01 -0700 Received: from fwd05.sul.t-online.de by mailout05.sul.t-online.com with smtp id 180ODv-00057E-0F; Sat, 12 Oct 2002 17:30:39 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.240.30]) by fmrl05.sul.t-online.com with esmtp id 180ODr-0YfGG8C; Sat, 12 Oct 2002 17:30:35 +0200 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9CFUQHb017521; Sat, 12 Oct 2002 17:30:26 +0200 Date: Sat, 12 Oct 2002 17:30:26 +0200 From: Axel Thimm To: Eric Sandeen , Chris Wedgwood , linux-xfs@oss.sgi.com, David Greaves Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems (was: root xfs filesystem executable bits bug comeback?) Message-ID: <20021012153026.GA17332@bonzo.nirvana> References: <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> <20021011020437.GA1144622@down.physik.fu-berlin.de> <20021011211538.GA27574@sgi.com> <20021011010713.GA4254@bonzo.nirvana> <1034370565.14233.33.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20021011211538.GA27574@sgi.com> <1034370565.14233.33.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The bug seems to be in the acl parts and is not restricted to root XFS-partitions (Eric, sorry for my bad wording about "root-mounted" partitions in the previous mail). It is also difficult to trigger - creating files is fine, copying them with "cp -p" to a XFS-partition (src is not relevant) is creating an (empty?) acl entry, which "test -x" misinterpretes if you are root (these acls also cannot be removed with setfacl -b and setfacl -k, and are also not diplayed with getfacl or getfattr). In general the bugs seem to be described as: o acl aware applications like "cp -p" create empty unremovable acls (or set some acl-is-here flag without truly holding an acl). o files with acls (empty or not) are always interpreted to have te permission flag set if you are root. Attached is a small test-case script as well as the output on my system (for root and a non-root user). Finally I also included a run on an older system (RH7.2 & XFS from april). Could you try the test case on your systems? BTW there is a small name clash between vanilla RedHat and SGI provided acl rpms: What SGI calls acl-devel, RedHat decided to call libacl-devel. But I think this is only a package dependency problem (the XFS acl-devel should obsolete libacl-devel or should adjust the name). On Fri, Oct 11, 2002 at 04:09:25PM -0500, Eric Sandeen wrote: > On Thu, 2002-10-10 at 20:07, Axel Thimm wrote: > > The bug fixed in > > http://marc.theaimsgroup.com/?l=linux-xfs&m=103001217021455&w=2 > > seems to have come back. An XFS root mounted partition returns always true on > > all files with "test -x". Non-root mounted XFS partitions are OK. As mentioned above "all files" is wrong (I had copied away and back the root partition while setting up the system, therefore all files had "empty" acls), as well as "only root partitions" (on the others I just tested "touch"). > I'll look at this one, since I fixed it last time... Are you running > this on a Red Hat 8.0 system? Also, by "root-mounted" you mean the root > filesystem, I guess? (i.e. "/"?) On Fri, Oct 11, 2002 at 04:15:39PM -0500, Nathan Straz wrote: > > > What kernel version(s)? > > The one mentioned in the subject, which is the prerelease version for > > SGI_XFS_1.2. > > I don't see this bug with the version in the subject. > [root@tarpon tmp]# df -Th . > Filesystem Type Size Used Avail Use% Mounted on > /dev/sda6 xfs 3.6G 909M 2.7G 25% / > [root@tarpon tmp]# uname -r > 2.4.18-14SGI_XFS_1.2a1 > [root@tarpon tmp]# touch newfile > [root@tarpon tmp]# chmod -x newfile > [root@tarpon tmp]# test -x newfile && echo xxx > [root@tarpon tmp]# chmod +x newfile > [root@tarpon tmp]# test -x newfile && echo xxx > xxx > [root@tarpon tmp]# rpm -q bash > bash-2.05b-5 > > Can you double check your kernel version and bash version? The system is what (I think) you would get from a custom->everything install of the SGI-XFS RedHat installer (I installed custom->minimal and included the rest by hand afterwards). -- Axel.Thimm@physik.fu-berlin.de --7AUc2qLy4jB3hD7Z Content-Type: application/x-sh Content-Disposition: attachment; filename="test-xfs-acl.sh" Content-Transfer-Encoding: quoted-printable #! /bin/sh testfile=3D/var/testing-XFS-acl echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> which kernel am I running?' uname -a echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> what packages are there? Check them' packages=3D"acl acl-devel attr attr-devel libacl libattr glibc fileutils ba= sh sh-utils" rpm --queryformat=3D'%{BUILDTIME} %{BUILDHOST}\t%{NAME}-%{VERSION}-%{RELEAS= E}\n' -q $packages \ | sort -n|TZ=3DUTC awk '{printf "%s %s\t%s\n", strftime("%a %b %e %H:%M:%S= %Z %Y",$1), $2, $3}' rpm -V $packages checkldd=3D"/bin/cp /bin/ls /usr/bin/*acl" echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> Check dynamic linking, where do sha= red libs of' $checkldd 'come from?' (cd /lib;rpm -qf `ldd /bin/cp /bin/ls /usr/bin/getfacl|grep '=3D>'|awk '{pr= int $1 " " $3}'`)|sort -u echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> where am I going to test it?' dir=3D`dirname $testfile` device=3D`cd "$dir"; df . | tail +2 | awk '{print $1}'` mount | grep "$device" rm -f ${testfile}* touch ${testfile}-1touched # cp ${testfile}-1touched ${testfile}-2cp-simple # cp -p ${testfile}-1touched ${testfile}-3cp-p # touch ${testfile}-4chacl chacl u::rw-,g::r--,o::r-- ${testfile}-4chacl # touch ${testfile}-5nonremovableacls chacl u::rw-,g::r--,o::r-- ${testfile}-5nonremovableacls #setfacl -b ${testfile}-5nonremovableacls #setfacl -k ${testfile}-5nonremovableacls # touch ${testfile}-6awithtrueacls setfacl -m u:nobody:r ${testfile}-6awithtrueacls # touch ${testfile}-6bwithtrueaclsthenremoved setfacl -m u:nobody:r ${testfile}-6bwithtrueaclsthenremoved setfacl -b ${testfile}-6bwithtrueaclsthenremoved setfacl -k ${testfile}-6bwithtrueaclsthenremoved echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> output of tests' for file in ${testfile}*; do test -x $file && echo $file BUG: test -x returns true \ || echo $file OK done echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> all but /var/testing-XFS-acl-6awith= trueacls should not have a + at the mods' ls -l ${testfile}* echo '# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> only /var/testing-XFS-acl-6awithtru= eacls should be listed' getfacl --absolute --skip-base ${testfile}* --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test-xfs-acl-as-root.log" # ==========> which kernel am I running? Linux puariko.nirvana 2.4.18-14SGI_XFS_1.2a1 #1 Wed Oct 2 05:51:55 CDT 2002 i686 athlon i386 GNU/Linux # ==========> what packages are there? Check them Fri Aug 23 20:01:11 UTC 2002 astest bash-2.05b-5 Thu Aug 29 20:56:33 UTC 2002 stripples.devel.redhat.com sh-utils-2.0.12-3 Mon Sep 2 11:21:27 UTC 2002 daffy.perf.redhat.com fileutils-4.1.9-11 Thu Sep 5 23:12:33 UTC 2002 daffy.perf.redhat.com glibc-2.2.93-5 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-2.0.11-0 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-devel-2.0.11-0 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com libattr-2.0.11-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-2.0.19-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-devel-2.0.19-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com libacl-2.0.19-0 # ==========> Check dynamic linking, where do shared libs of /bin/cp /bin/ls /usr/bin/chacl /usr/bin/getfacl /usr/bin/setfacl come from? file /lib/libtermcap.so.2 is not owned by any package file libtermcap.so.2 is not owned by any package glibc-2.2.93-5 libacl-2.0.19-0 libattr-2.0.11-0 # ==========> where am I going to test it? /dev/hda7 on /var type xfs (rw) # ==========> output of tests /var/testing-XFS-acl-1touched OK /var/testing-XFS-acl-2cp-simple OK /var/testing-XFS-acl-3cp-p BUG: test -x returns true /var/testing-XFS-acl-4chacl BUG: test -x returns true /var/testing-XFS-acl-5nonremovableacls BUG: test -x returns true /var/testing-XFS-acl-6awithtrueacls BUG: test -x returns true /var/testing-XFS-acl-6bwithtrueaclsthenremoved BUG: test -x returns true # ==========> all but /var/testing-XFS-acl-6awithtrueacls should not have a + at the mods -rw-r--r-- 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-1touched -rw-r--r-- 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-2cp-simple -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-3cp-p -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-4chacl -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-5nonremovableacls -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-6awithtrueacls -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-acl-6bwithtrueaclsthenremoved # ==========> only /var/testing-XFS-acl-6awithtrueacls should be listed # file: /var/testing-XFS-acl-6awithtrueacls # owner: root # group: root user::rw- user:nobody:r-- group::r-- mask::r-- other::r-- --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test-xfs-acl-as-non-priviledged-user.log" # ==========> which kernel am I running? Linux puariko.nirvana 2.4.18-14SGI_XFS_1.2a1 #1 Wed Oct 2 05:51:55 CDT 2002 i686 athlon i386 GNU/Linux # ==========> what packages are there? Check them Fri Aug 23 20:01:11 UTC 2002 astest bash-2.05b-5 Thu Aug 29 20:56:33 UTC 2002 stripples.devel.redhat.com sh-utils-2.0.12-3 Mon Sep 2 11:21:27 UTC 2002 daffy.perf.redhat.com fileutils-4.1.9-11 Thu Sep 5 23:12:33 UTC 2002 daffy.perf.redhat.com glibc-2.2.93-5 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-2.0.11-0 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-devel-2.0.11-0 Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com libattr-2.0.11-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-2.0.19-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-devel-2.0.19-0 Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com libacl-2.0.19-0 ..?..... /usr/sbin/glibc_post_upgrade # ==========> Check dynamic linking, where do shared libs of /bin/cp /bin/ls /usr/bin/chacl /usr/bin/getfacl /usr/bin/setfacl come from? file /lib/libtermcap.so.2 is not owned by any package file libtermcap.so.2 is not owned by any package glibc-2.2.93-5 libacl-2.0.19-0 libattr-2.0.11-0 # ==========> where am I going to test it? /dev/hda7 on /var type xfs (rw) # ==========> output of tests /var/testing-XFS-acl-1touched OK /var/testing-XFS-acl-2cp-simple OK /var/testing-XFS-acl-3cp-p OK /var/testing-XFS-acl-4chacl OK /var/testing-XFS-acl-5nonremovableacls OK /var/testing-XFS-acl-6awithtrueacls OK /var/testing-XFS-acl-6bwithtrueaclsthenremoved OK # ==========> all but /var/testing-XFS-acl-6awithtrueacls should not have a + at the mods -rw-r--r-- 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-1touched -rw-r--r-- 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-2cp-simple -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-3cp-p -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-4chacl -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-5nonremovableacls -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-6awithtrueacls -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-acl-6bwithtrueaclsthenremoved # ==========> only /var/testing-XFS-acl-6awithtrueacls should be listed # file: /var/testing-XFS-acl-6awithtrueacls # owner: thimm # group: ag-linke user::rw- user:nobody:r-- group::r-- mask::r-- other::r-- --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test-xfs-acl-as-root-on-older-system.log" # ==========> which kernel am I running? Linux fs2 2.4.19-pre6-rmap12i-xfs-shawn11-fs #1 Tue Apr 16 09:17:43 CEST 2002 i686 unknown # ==========> what packages are there? Check them Mon Jul 9 12:56:25 UTC 2001 stripples.devel.redhat.com bash-2.05-8 Mon Jul 23 16:23:50 UTC 2001 stripples.devel.redhat.com sh-utils-2.0.11-5 Thu Aug 9 13:01:23 UTC 2001 stripples.devel.redhat.com fileutils-4.1-4 Tue Apr 16 15:03:44 UTC 2002 lite attr-2.0.7-0 Tue Apr 16 15:03:44 UTC 2002 lite attr-devel-2.0.7-0 Tue Apr 16 15:03:44 UTC 2002 lite libattr-2.0.7-0 Tue Apr 16 15:05:26 UTC 2002 lite acl-2.0.9-0 Tue Apr 16 15:05:26 UTC 2002 lite acl-devel-2.0.9-0 Tue Apr 16 15:05:26 UTC 2002 lite libacl-2.0.9-0 Mon Sep 9 16:10:30 UTC 2002 daffy.perf.redhat.com glibc-2.2.4-30 .......T c /etc/rpc # ==========> Check dynamic linking, where do shared libs of /bin/cp /bin/ls /usr/bin/chacl /usr/bin/getfacl /usr/bin/setfacl come from? file /lib/libtermcap.so.2 is not owned by any package file libtermcap.so.2 is not owned by any package glibc-2.2.4-30 libacl-2.0.9-0 libattr-2.0.7-0 # ==========> where am I going to test it? /dev/sda6 on /var type xfs (rw) # ==========> output of tests /var/testing-XFS-acl-1touched OK /var/testing-XFS-acl-2cp-simple OK /var/testing-XFS-acl-3cp-p OK /var/testing-XFS-acl-4chacl OK /var/testing-XFS-acl-5nonremovableacls OK /var/testing-XFS-acl-6awithtrueacls OK /var/testing-XFS-acl-6bwithtrueaclsthenremoved OK # ==========> all but /var/testing-XFS-acl-6awithtrueacls should not have a + at the mods -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-1touched -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-2cp-simple -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-3cp-p -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-4chacl -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-5nonremovableacls -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-6awithtrueacls -rw-r--r-- 1 root root 0 Oct 12 17:24 /var/testing-XFS-acl-6bwithtrueaclsthenremoved # ==========> only /var/testing-XFS-acl-6awithtrueacls should be listed # file: /var/testing-XFS-acl-6awithtrueacls # owner: root # group: root user::rw- user:nobody:r-- group::r-- mask::r-- other::r-- --7AUc2qLy4jB3hD7Z-- From owner-linux-xfs@oss.sgi.com Sat Oct 12 08:36:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 08:36:24 -0700 (PDT) Received: from cpw.math.columbia.edu (root@cpw.math.columbia.edu [128.59.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CFaLtG005497 for ; Sat, 12 Oct 2002 08:36:21 -0700 Received: from cpw.math.columbia.edu (atici@localhost [127.0.0.1]) by cpw.math.columbia.edu (8.12.6/8.12.6) with ESMTP id g9CFaFRU027139; Sat, 12 Oct 2002 11:36:15 -0400 Received: from localhost (atici@localhost) by cpw.math.columbia.edu (8.12.6/8.12.6/Submit) with ESMTP id g9CFaFu4027136; Sat, 12 Oct 2002 11:36:15 -0400 Date: Sat, 12 Oct 2002 11:36:15 -0400 (EDT) From: Alp ATICI To: Christoph Hellwig cc: linux-xfs@oss.sgi.com Subject: Re: Work Items In-Reply-To: <20021012135641.B16453@infradead.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.20 (www . roaringpenguin . com / mimedefang) X-archive-position: 945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: atici@cpw.math.columbia.edu Precedence: bulk X-list: linux-xfs On Sat, 12 Oct 2002, Christoph Hellwig wrote: > XFS does have 64bit inodes, Linux VFS doesn't. Hmm but check this: http://marc.theaimsgroup.com/?l=linux-xfs&m=100740237824601&w=2 (TAKE - restrict xfs inodes to 32 bits) http://marc.theaimsgroup.com/?l=linux-xfs&m=99928901910853&w=2 (TAKE - mkfs/growfs 32-bit inode number awareness) Now are these restrictions going to be released after the latest 2.5 kernel (that includes Peter Chubb's 64-bit patches that removes 2TB limit)? or that doesn't mean Linux VFS supports 64 bit inodes still? Alp From owner-linux-xfs@oss.sgi.com Sat Oct 12 11:47:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 11:47:40 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CIlZtG007404 for ; Sat, 12 Oct 2002 11:47:36 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA92943; Sat, 12 Oct 2002 13:47:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA45820; Sat, 12 Oct 2002 13:47:29 -0500 (CDT) Date: Sat, 12 Oct 2002 13:44:41 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Alp ATICI cc: Christoph Hellwig , Subject: Re: Work Items In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Internally, XFS can handle 64-bit inodes and 64-bit block numbers. However, since Linux VFS cannot handle 64-bit inodes, XFS on Linux is -always- restricted to 32 bit inodes. see the unconditional "args->flags |= XFSMNT_32BITINODES;" in fs/xfs/linux/xfs_super.c The "32bitinodes" (sp?) mount option was recently added to Irix to restrict inode numbers to 32-bits, for applications that could not handle 64-bit inodes. Does Peter's patch also allow 64-bit inodes? A glance over the page does not mention inode number changes, but I have not looked closely at the patch. With Peter's patch, lots of XFS's 64-bit-ness can probably be turned back on. (see also XFS_BIG_FILESYSTEMS in fs/xfs/xfs_types.h) -Eric On Sat, 12 Oct 2002, Alp ATICI wrote: > On Sat, 12 Oct 2002, Christoph Hellwig wrote: > > > XFS does have 64bit inodes, Linux VFS doesn't. > > Hmm but check this: > http://marc.theaimsgroup.com/?l=linux-xfs&m=100740237824601&w=2 > (TAKE - restrict xfs inodes to 32 bits) > > http://marc.theaimsgroup.com/?l=linux-xfs&m=99928901910853&w=2 > (TAKE - mkfs/growfs 32-bit inode number awareness) > > Now are these restrictions going to be released after the latest 2.5 > kernel (that includes Peter Chubb's 64-bit patches that removes 2TB > limit)? or that doesn't mean Linux VFS supports 64 bit inodes still? > Alp > > From owner-linux-xfs@oss.sgi.com Sat Oct 12 12:10:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 12:10:48 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CJAktG008028 for ; Sat, 12 Oct 2002 12:10:46 -0700 Received: from attbi.com ([66.56.46.164]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021012191040.WQL17158.rwcrmhc53.attbi.com@attbi.com> for ; Sat, 12 Oct 2002 19:10:40 +0000 Message-ID: <3DA873B0.5080601@attbi.com> Date: Sat, 12 Oct 2002 15:10:40 -0400 From: James Haydon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS-1.2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhaydon@attbi.com Precedence: bulk X-list: linux-xfs I thought I'd let you know I had no problem with the installation that I did'nt have with Redhat 8.0. Does Debian HPPA have XFS? Thanks James From owner-linux-xfs@oss.sgi.com Sat Oct 12 12:34:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 12:34:04 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CJY1tG008603 for ; Sat, 12 Oct 2002 12:34:02 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id DBA95145B3; Sat, 12 Oct 2002 21:33:55 +0200 (MEST) Date: Sat, 12 Oct 2002 21:33:51 +0200 From: Andi Kleen To: Eric Sandeen Cc: Alp ATICI , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Work Items Message-ID: <20021012213351.A27559@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Sat, Oct 12, 2002 at 01:44:41PM -0500, Eric Sandeen wrote: > Internally, XFS can handle 64-bit inodes and 64-bit block numbers. > > However, since Linux VFS cannot handle 64-bit inodes, XFS on Linux > is -always- restricted to 32 bit inodes. Linux VFS can handle them in a limited way - otherwise e.g. NFSv3 wouldn't work. You can use custom iget functions to look them up in the inode cache. What doesn't work is exporting them to user space via stat64() For XFS it should be enough for now. > With Peter's patch, lots of XFS's 64-bit-ness can probably be turned back on. No, but even 2.4 supports it in a limited way. -Andi From owner-linux-xfs@oss.sgi.com Sat Oct 12 13:43:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 13:43:28 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CKhJtG009573 for ; Sat, 12 Oct 2002 13:43:20 -0700 Received: from erbenson.alaska.net (102-pm30.nwc.alaska.net [209.112.158.102]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9CKhHCc007919 for ; Sat, 12 Oct 2002 12:43:17 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 249E03A11 for ; Sat, 12 Oct 2002 12:43:16 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 3DA3C4104E2; Sat, 12 Oct 2002 12:43:16 -0800 (AKDT) Date: Sat, 12 Oct 2002 12:43:16 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems (was: root xfs filesystem executable bits bug comeback?) Message-ID: <20021012204316.GP13549@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> <20021011020437.GA1144622@down.physik.fu-berlin.de> <20021011211538.GA27574@sgi.com> <20021011010713.GA4254@bonzo.nirvana> <1034370565.14233.33.camel@stout.americas.sgi.com> <20021012153026.GA17332@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PdAWLd+WEPmMbsbx" Content-Disposition: inline In-Reply-To: <20021012153026.GA17332@bonzo.nirvana> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --PdAWLd+WEPmMbsbx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2002 at 05:30:26PM +0200, Axel Thimm wrote: > The bug seems to be in the acl parts and is not restricted to root > XFS-partitions (Eric, sorry for my bad wording about "root-mounted" parti= tions > in the previous mail). >=20 > It is also difficult to trigger - creating files is fine, copying them wi= th > "cp -p" to a XFS-partition (src is not relevant) is creating an (empty?) = acl > entry, which "test -x" misinterpretes if you are root (these acls also ca= nnot > be removed with setfacl -b and setfacl -k, and are also not diplayed with > getfacl or getfattr). yes this is exceedingly annoying since acl aware ls shows such files with a + on the permissions, which is erroneous. you can see the acls with the following: getfattr -m . file you will see a system.posix_acl_access attribute (system.* is not displayed by default). you can remove them with: setfattr -x system.posix_acl_access file > In general the bugs seem to be described as: > o acl aware applications like "cp -p" create empty unremovable acls (or s= et > some acl-is-here flag without truly holding an acl). the problem is XFS is not removing acl xattrs when they contain nothing that can't be stored in the inode mode feild. this also affects directories with basic default acls (which only, say turn on the group write permission, all new files should, and do have only basic unix permissions, but still have a acl xattr making things like ls believe there is an acl when there isn't one). i propose this be fixed by either adding a check to see if the acl has anything more then the basic unix permissions, and if so dispose with creating an xattr. and/or in the function which syncs the inode mode bits with the acl's basic entries, if the acl does not contain any extended ACEs then delete the acl attribute. fwiw SunOS with acl support does not exhibit these problems. > o files with acls (empty or not) are always interpreted to have te permis= sion > flag set if you are root. s/te/the execute/ i presume.=20 yes thats a separate bug. > BTW there is a small name clash between vanilla RedHat and SGI provided a= cl > rpms: What SGI calls acl-devel, RedHat decided to call libacl-devel. But I > think this is only a package dependency problem (the XFS acl-devel should > obsolete libacl-devel or should adjust the name). libacl is the correct name. this is already planned to be adjusted for at least debian which has strict (and quite sane) policies on the naming of these sorts of packages. > /var/testing-XFS-acl-2cp-simple OK > /var/testing-XFS-acl-3cp-p BUG: test -x returns true > /var/testing-XFS-acl-4chacl BUG: test -x returns true > /var/testing-XFS-acl-5nonremovableacls BUG: test -x returns true > /var/testing-XFS-acl-6awithtrueacls BUG: test -x returns true > /var/testing-XFS-acl-6bwithtrueaclsthenremoved BUG: test -x returns true can you try this test by removing the acl with the above setfattr command instead of setfacl (which seems to be partly broken in regards to acl removal)=20 > # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> all but /var/testing-XFS-acl-6awithtrue= acls should not have a + at the mods > -rw-r--r-- 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-1touched > -rw-r--r-- 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-2cp-simple > -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-3cp-p > -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-4chacl > -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-5nonremovableacls > -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-6awithtrueacls > -rw-r--r--+ 1 root root 0 Oct 12 17:15 /var/testing-XFS-= acl-6bwithtrueaclsthenremoved notice all the + that should not be there. > -rw-r--r-- 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-1touched > -rw-r--r-- 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-2cp-simple > -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-3cp-p > -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-4chacl > -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-5nonremovableacls > -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-6awithtrueacls > -rw-r--r--+ 1 thimm ag-linke 0 Oct 12 17:15 /var/testing-XFS-= acl-6bwithtrueaclsthenremoved still a bug, only one of those should have a + > # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> only /var/testing-XFS-acl-6awithtrueacl= s should be listed > # file: /var/testing-XFS-acl-6awithtrueacls > # owner: thimm > # group: ag-linke > user::rw- > user:nobody:r-- > group::r-- > mask::r-- > other::r-- --=20 Ethan Benson http://www.alaska.net/~erbenson/ --PdAWLd+WEPmMbsbx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2oiWMACgkQJKx7GixEevw5BgCfY5Aq/NC82vf5nS+XJuHoj6/H 4roAnAiyXSsDT88lkVjuZ41GAG8sslQ+ =4jj8 -----END PGP SIGNATURE----- --PdAWLd+WEPmMbsbx-- From owner-linux-xfs@oss.sgi.com Sat Oct 12 13:46:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 13:46:28 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CKkQtG010023 for ; Sat, 12 Oct 2002 13:46:26 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA20969; Sat, 12 Oct 2002 15:46:21 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-10.corp.sgi.com [134.15.64.10]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA03134; Sat, 12 Oct 2002 15:46:20 -0500 (CDT) Subject: Re: Work Items From: Stephen Lord To: Alp ATICI Cc: Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 12 Oct 2002 15:42:33 -0500 Message-Id: <1034455355.1033.4.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 2002-10-12 at 10:36, Alp ATICI wrote: > On Sat, 12 Oct 2002, Christoph Hellwig wrote: > > > XFS does have 64bit inodes, Linux VFS doesn't. > > Hmm but check this: > http://marc.theaimsgroup.com/?l=linux-xfs&m=100740237824601&w=2 > (TAKE - restrict xfs inodes to 32 bits) > > http://marc.theaimsgroup.com/?l=linux-xfs&m=99928901910853&w=2 > (TAKE - mkfs/growfs 32-bit inode number awareness) > > Now are these restrictions going to be released after the latest 2.5 > kernel (that includes Peter Chubb's 64-bit patches that removes 2TB > limit)? or that doesn't mean Linux VFS supports 64 bit inodes still? > Alp > The 2 Tbyte limit and 32 bit inodes are totally different things. The 32 bit inode number issue can be solved internally within the kernel, until you get to system calls, and a number of system calls want to make an inode number available to user space. Right now there is no room in the structures returned from these calls for 64 bits of inode space. In order for xfs to function beyond the 2 Tbyte limit, all we need to do is enable large filesystem support again in XFS. This is a one character change. In xfs_types.h define XFS_BIG_FILESYSTEMS to 1 instead of zero. Steve From owner-linux-xfs@oss.sgi.com Sat Oct 12 14:57:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 14:57:39 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CLvXtG010756 for ; Sat, 12 Oct 2002 14:57:34 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 967FA14AFA; Sat, 12 Oct 2002 23:57:28 +0200 (MEST) Date: Sat, 12 Oct 2002 23:57:27 +0200 From: Andi Kleen To: Stephen Lord Cc: Alp ATICI , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Work Items Message-ID: <20021012235727.A28750@wotan.suse.de> References: <1034455355.1033.4.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1034455355.1033.4.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Sat, Oct 12, 2002 at 03:42:33PM -0500, Steve Lord wrote: > The 2 Tbyte limit and 32 bit inodes are totally different things. > The 32 bit inode number issue can be solved internally within > the kernel, until you get to system calls, and a number of system > calls want to make an inode number available to user space. Right > now there is no room in the structures returned from these calls > for 64 bits of inode space. Actually there is. stat64 has enough space for it and glibc supports it too. Just the current i386 kernel zeroes the upper 32bits because internally on 32bit systems ino_t is only defined as long (=32bit. On 64bit platforms like x86-64 or ia64 it should work fine because ino_t is 64bit then asm-i386/posix_types.h typedef unsigned long __kernel_ino_t; asm-i386/stat.h: struct stat64 { ... unsigned long long st_ino; -Andi From owner-linux-xfs@oss.sgi.com Sat Oct 12 20:59:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 20:59:47 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9D3xftG014138 for ; Sat, 12 Oct 2002 20:59:42 -0700 Received: from fwd00.sul.t-online.de by mailout11.sul.t-online.com with smtp id 180Zum-0005MA-01; Sun, 13 Oct 2002 05:59:40 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.227.64]) by fmrl00.sul.t-online.com with esmtp id 180Zul-0xhoOGC; Sun, 13 Oct 2002 05:59:39 +0200 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9D3xTEg004611; Sun, 13 Oct 2002 05:59:29 +0200 Date: Sun, 13 Oct 2002 05:59:29 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems Message-ID: <20021013035929.GA4505@bonzo.nirvana> References: <1034370565.14233.33.camel@stout.americas.sgi.com> <20021012153026.GA17332@bonzo.nirvana> <20021012204316.GP13549@plato.local.lan> <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> <20021011020437.GA1144622@down.physik.fu-berlin.de> <20021011211538.GA27574@sgi.com> <20021011010713.GA4254@bonzo.nirvana> <1034370565.14233.33.camel@stout.americas.sgi.com> <20021012153026.GA17332@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021012204316.GP13549@plato.local.lan> <20021012153026.GA17332@bonzo.nirvana> User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs On Sat, Oct 12, 2002 at 05:30:26PM +0200, Axel Thimm wrote: > # ==========> what packages are there? Check them > Fri Aug 23 20:01:11 UTC 2002 astest bash-2.05b-5 > Thu Aug 29 20:56:33 UTC 2002 stripples.devel.redhat.com sh-utils-2.0.12-3 > Mon Sep 2 11:21:27 UTC 2002 daffy.perf.redhat.com fileutils-4.1.9-11 > Thu Sep 5 23:12:33 UTC 2002 daffy.perf.redhat.com glibc-2.2.93-5 > Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-2.0.11-0 > Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com attr-devel-2.0.11-0 > Tue Oct 1 18:44:14 UTC 2002 stout.americas.sgi.com libattr-2.0.11-0 > Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-2.0.19-0 > Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com acl-devel-2.0.19-0 > Tue Oct 1 18:45:14 UTC 2002 stout.americas.sgi.com libacl-2.0.19-0 I just found out, that I was using the rpms from http://oss.sgi.com/projects/xfs/download/cmd_rpms instead of the ones in 1.2pre1. But switching to them does not make any difference. On Sat, Oct 12, 2002 at 12:43:16PM -0800, Ethan Benson wrote: > On Sat, Oct 12, 2002 at 05:30:26PM +0200, Axel Thimm wrote: > > The bug seems to be in the acl parts and is not restricted to root > > XFS-partitions [...] > > yes this is exceedingly annoying since acl aware ls shows such files > with a + on the permissions, which is erroneous. > > you can see the acls with the following: > > getfattr -m . file > > you will see a system.posix_acl_access attribute (system.* is not > displayed by default). I also see a xfsroot.SGI_ACL_FILE entry. > you can remove them with: > setfattr -x system.posix_acl_access file Which also removes the xfsroot.SGI_ACL_FILE entry (as it should, I guess). > can you try this test by removing the acl with the above setfattr > command instead of setfacl (which seems to be partly broken in regards > to acl removal) Yes, it works as you describe it. Thanks, it works better for restoring my files then copying them back and forth with non-acl aware tools (like local rsync). So there are three bugs? a) XFS code should automatically remove ACL attributes if not needed anymore. b) same for setfacl. c) files with ACLs appear as executable for root. If a) is not done in the kernel but in the userland, then maybe a) & b) are the same bug. -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Sat Oct 12 21:24:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 12 Oct 2002 21:24:23 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9D4OJtG014728 for ; Sat, 12 Oct 2002 21:24:19 -0700 Received: from erbenson.alaska.net (102-pm30.nwc.alaska.net [209.112.158.102]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9D4OHCc044549 for ; Sat, 12 Oct 2002 20:24:18 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 125A23A11 for ; Sat, 12 Oct 2002 20:24:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 145254104E2; Sat, 12 Oct 2002 20:24:17 -0800 (AKDT) Date: Sat, 12 Oct 2002 20:24:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems Message-ID: <20021013042416.GC3281@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021012153026.GA17332@bonzo.nirvana> <20021012204316.GP13549@plato.local.lan> <20021011010713.GA4254@bonzo.nirvana> <20021011014047.GA27651@tapu.f00f.org> <20021011020437.GA1144622@down.physik.fu-berlin.de> <20021011211538.GA27574@sgi.com> <20021011010713.GA4254@bonzo.nirvana> <1034370565.14233.33.camel@stout.americas.sgi.com> <20021012153026.GA17332@bonzo.nirvana> <20021013035929.GA4505@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="da4uJneut+ArUgXk" Content-Disposition: inline In-Reply-To: <20021013035929.GA4505@bonzo.nirvana> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --da4uJneut+ArUgXk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 13, 2002 at 05:59:29AM +0200, Axel Thimm wrote: > > you will see a system.posix_acl_access attribute (system.* is not > > displayed by default). >=20 > I also see a xfsroot.SGI_ACL_FILE entry. yes you will see that if you run getfattr as root. you don't need to mess with that one. > > you can remove them with: > > setfattr -x system.posix_acl_access file >=20 > Which also removes the xfsroot.SGI_ACL_FILE entry (as it should, I guess). yes, the xfsroot attribute handled automatically in the kernel. > > can you try this test by removing the acl with the above setfattr > > command instead of setfacl (which seems to be partly broken in regards > > to acl removal)=20 >=20 > Yes, it works as you describe it. Thanks, it works better for restoring my > files then copying them back and forth with non-acl aware tools (like loc= al > rsync). >=20 > So there are three bugs? > a) XFS code should automatically remove ACL attributes if not needed anym= ore. yes > b) same for setfacl. maybe, i tend to think not, it really needs to be handled in the kernel automatically to be truly effective. > c) files with ACLs appear as executable for root. yes > If a) is not done in the kernel but in the userland, then maybe a) & b) a= re > the same bug. i don't think it can be done too effectivly in userland.. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --da4uJneut+ArUgXk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2o9XAACgkQJKx7GixEevytuwCfamAa62Qs4BF2kaQ1wHsi1DBU AmgAn1U6P6hqYuBTUPooEJVCg7bMi7VB =KSYz -----END PGP SIGNATURE----- --da4uJneut+ArUgXk-- From owner-linux-xfs@oss.sgi.com Sun Oct 13 03:45:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Oct 2002 03:45:58 -0700 (PDT) Received: from aeimail.aei.ca (root@aeimail.aei.ca [206.123.6.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DAjptG018195 for ; Sun, 13 Oct 2002 03:45:51 -0700 Received: from comotion (dsl-129-59.aei.ca [66.36.129.59]) by aeimail.aei.ca (8.11.6/8.10.1) with ESMTP id g9DAjnM05317 for ; Sun, 13 Oct 2002 06:45:49 -0400 (EDT) Date: Sun, 13 Oct 2002 06:47:28 -0400 From: Kacper Wysocki To: linux-xfs@oss.sgi.com Subject: xfsdump segfaults, xfs_repair suffers fatality Message-ID: <20021013064728.C1968@comotion.aei.ca> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 66 X-archive-position: 954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kacperw@online.no Precedence: bulk X-list: linux-xfs Hi, I'm running a hardware raid 0 system with 10 disks, one of which recently(er, today) failed. This was a good 40GB of data on a 70GB logical drive, and it's all striped, which usually means it's all lost. But not really, cause you'd think the data on all the drives that didn't fail still is there? So I managed to replace the disk, rebuild the fs (with xfs_repair) and get a running xfs file system with a good amount of lost+founds. Problem is, xfs_repair failed with the following message: fatal error -- can't read block 0 for directory inode 50331793 I assume this is an I/O error, as that's where xfs_repair can't help. I'm thinking the only way to remedy this is to dump the fs and low-level format the drive, but I don't have the storage space currently. Also, after this error message I already had quite the populated lost+found directory, and went about looking through it. About half way through I had the crazy thought of re-running xfs_repair without realizing this would remove all previous lost+found entries!! Now, about a year ago I posted to this list about how to recover deleted files in the xfs file system, and got to know how it's virtually impossible. What was suggested then was that one could "xfsdump -J - /dev/rd/c0d0p1 | xfsrestore - dump -i" to recover some of the data. In addition my (very limited) understanding of filesystems and I/O tells me someone should be able to write an application that searches the drive(dump) in question and pulls out any complete files with recognized file type it finds (based on magic no's etc). I'm thinking someone already wrote such an application, and I'm thinking it's GPL'ed or something. (HA! *hoping* more like) There are two problems with the above: 1. I haven't been able to find such an application 2. xfsdump segfaults. It's weird, because I know It's worked before on the same system. A simple xfsdump - /dev/rd/c0d0p1 yeilds the following: xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.2 (dump format 3.0) - Running single-threaded xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of comotion:/home xfsdump: dump date: Sun Oct 13 06:37:51 2002 xfsdump: session id: 04323a2f-089e-47e5-afa8-71b2f6e3b6fd xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 13563575104 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories Segmentation fault Could you please tell me what I should do to get xfsdump working? What is wrong with xfs_repair? Is it because I've seriously b0rked the fs? Does anyone know about an app fitting my abovementioned description? Sincerely, Kacper Wysocki From owner-linux-xfs@oss.sgi.com Sun Oct 13 05:17:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Oct 2002 05:17:47 -0700 (PDT) Received: from hotmail.com (f169.law12.hotmail.com [64.4.19.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DCHgtG024348 for ; Sun, 13 Oct 2002 05:17:42 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 13 Oct 2002 05:17:29 -0700 Received: from 217.127.197.115 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 13 Oct 2002 12:17:29 GMT X-Originating-IP: [217.127.197.115] From: "Pablo Hdez" To: linux-xfs@oss.sgi.com Subject: artwork-redhat installer Date: Sun, 13 Oct 2002 12:17:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 13 Oct 2002 12:17:29.0613 (UTC) FILETIME=[7FF25BD0:01C272B2] X-archive-position: 955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: homeless3d@hotmail.com Precedence: bulk X-list: linux-xfs I have used sgi's installer for redhat 7.2 and i'm using redhat8.0 now and i can see that graphic field is not right implemented yet (i know it's no priority but it's very helpfull). Red hat base doesn't include the fantastic XFS unfortunately. I consider this installer essential, so i'd like to help as far as my possibilities. i've created an artwork for anaconda more elaborated (icons, head, splash screens...) and i'd like it'll be included in the official one. If you consider that my work can be interesting you can contact with me mailing to homeless3d@hotmail.com. yours faithfully Pablo Hdez-M Saiz _________________________________________________________________ MSN. M醩 趖il cada D韆. http://www.msn.es/intmap/ From owner-linux-xfs@oss.sgi.com Sun Oct 13 05:29:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Oct 2002 05:29:38 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DCTZtG024823 for ; Sun, 13 Oct 2002 05:29:36 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 180hsE-0003xo-00; Sun, 13 Oct 2002 13:29:34 +0100 Date: Sun, 13 Oct 2002 13:29:34 +0100 From: Christoph Hellwig To: Alp ATICI Cc: linux-xfs@oss.sgi.com Subject: Re: Work Items Message-ID: <20021013132934.B15151@infradead.org> References: <20021012135641.B16453@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from atici@math.columbia.edu on Sat, Oct 12, 2002 at 11:36:15AM -0400 X-archive-position: 956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sat, Oct 12, 2002 at 11:36:15AM -0400, Alp ATICI wrote: > Now are these restrictions going to be released after the latest 2.5 > kernel (that includes Peter Chubb's 64-bit patches that removes 2TB > limit)? or that doesn't mean Linux VFS supports 64 bit inodes still? As said above Linux VFS can't cope with 64bit inodes still. Also most userspace (not only on Linux) can' cope with > 32bt inodes at all, thus is why XFS has a 32bit inodes option on IRIX now, too From owner-linux-xfs@oss.sgi.com Sun Oct 13 09:17:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Oct 2002 09:17:16 -0700 (PDT) Received: from jefferson.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DGHAtG027481 for ; Sun, 13 Oct 2002 09:17:10 -0700 To: Axel Thimm Cc: Russell Cattelan , linux-xfs@oss.sgi.com MIME-Version: 1.0 From: ctooley@amoa.org Subject: Re: 1.2 PreRelease avaliable Date: Sun, 13 Oct 2002 11:02:06 -0500 Message-ID: X-MIMETrack: Serialize by Router on AMOA/AMOA(Release 5.0.8 |June 18, 2001) at 10/13/2002 11:02:13 AM MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-archive-position: 957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs

The only thing that I've noticed that hasn't been noted on the list is d= isc ordering.  The first time that the SGI disc is asked for it is ref= erred to Disc 6.  After it's complete Disc 2 is asked for, putting in = Disc 2 gets you an error that you've inserted the wrong SGI XFS cd.  C= licking ok ejects the disc and Disc 1 is requested.

I greatly appreci= ate the work done on the installer.  Thank you very much.  It wou= ld not suprise me if these things were just not fixed as it's not really yo= ur job to supply RedHat specific installers, it's RedHat's.  If you ch= oose to keep the current installer though, I'd suggest putting a big list o= f warnings in a README about the known problems.  Anyway, thank you ag= ain.

 

#############################################
Ch= ris Tooley voice: 512-495-9224x289
Austin Museum of Art pager: 512-613-2= 603
IT Coordinator
823 Congress Ave
Austin, TX 78701
##########= #####################################

 
Axe= l Thimm <Axel.Thimm@physik.fu-berlin.de>
Sent by: linux-xfs-bounce@oss.sgi.com
10/10/2002 = 09:22 PM ZE2

To: Russel= l Cattelan <cattelan@thebarn.com>
cc: linux-xfs@oss.sgi.com
bcc:
Subject: Re: 1.2 PreRelease ava= liable


First of = all thanks for spinning a RedHat installer, and also that fast!
<= BR>Good news:
+ The supplied kernel sou= rces seem to work very well.
+ Th