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.
+ The installer does work when installing a= minimal system. Having a bootable
 system with XFS-fs and ssh is = already very helpfull. :)

Bu= gs:
- The installer will not work if you try to install "custom->= ;everything".
 After having completed 268 of 1468 packages (7= 54MB of 4691MB) the installer
 chokes on anaconda:

<= FONT FACE=3D"Monospace,Courier">  > There was an error installing a= naconda-8.0-XFS=5F1. This can
 > indicate media failure, lack o= f disk space, and/or hardware
 > problems. This is a fatal erro= r and your install will be aborted.
 > Please verify your media= and try your install again.
 >
 > Press the OK but= ton to reboot your system.

=  anaconda is 9.276 KBytes and I switched to the shell console and veri= fied
 that all partitions had enough space left (smallest was /boo= t and had 45M).
- I also tried a network install for XFS "custom-&g= t;everything" which aborted in
 a python exception of anacond= a (something about inappropriate numers of
 arguments passed - sor= ry I didn't dump the error to a diskette).

Note that I did checked the media to be OK and also confirme= d this behaviour
on another station. Furthermore the RedHat vanilla inst= aller 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 to= ward actually getting a 1.2 release
> ready.
> ftp://oss.sgi.com/projects/xfs/Re= lease-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
> obscur= e end case problems so most people won't hit them.
>
> Please p= ound on, run over, throw things etc and report problems, success
> we= ather conditions.
>
> The installer iso is also available. I wi= ll 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 triv= ial.
>
> A few known problems exist and will probably not be fi= xed unless
> somebody wants to send in a fix.
>   1) Grud = does not install correctly during the install, anybody
> wishing &nbs= p;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 wi= th anaconda and is not easily fixed. The workaround for this
> is to = change the fstab to contain the actual device names before
> attempti= ng 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 Mon Oct 14 04:58:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 04:58:30 -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 g9EBwQtG021693 for ; Mon, 14 Oct 2002 04:58:27 -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 1813qT-00083k-00; Mon, 14 Oct 2002 12:57:13 +0100 Message-ID: <3DAAB119.2EEBD01C@moving-picture.com> Date: Mon, 14 Oct 2002 12:57:13 +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> <3DA70DEE.190877FF@moving-picture.com> <1034358502.13979.18.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: 958 X-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 Unfortunately it doesn't work - I get (with XFS 1.1): xfs_log_recover.c: In function `xlog_find_tail': xfs_log_recover.c:841: structure has no member named `m_logdev_targp' I had a quick look through the source of v1.1 and the recent 2.4.19 patch - but got lost ... James Pearson Eric Sandeen wrote: > > 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 Mon Oct 14 06:54:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 06:54: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 g9EDsOtG008883 for ; Mon, 14 Oct 2002 06:54:24 -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 IAA97673; Mon, 14 Oct 2002 08:54:18 -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 IAA86359; Mon, 14 Oct 2002 08:54:18 -0500 (CDT) Date: Mon, 14 Oct 2002 08:51:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: James Pearson cc: Stephen Lord , Subject: Re: Log corruption? In-Reply-To: <3DAAB119.2EEBD01C@moving-picture.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 959 X-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 Whoops, sorry, that changed since 1.1. Try this, then... if (!is_read_only(log->l_mp->m_logdev)) { error = xlog_clear_stale_blocks(log, tail_lsn); } On Mon, 14 Oct 2002, James Pearson wrote: > Unfortunately it doesn't work - I get (with XFS 1.1): > > xfs_log_recover.c: In function `xlog_find_tail': > xfs_log_recover.c:841: structure has no member named `m_logdev_targp' > > I had a quick look through the source of v1.1 and the recent 2.4.19 > patch - but got lost ... > > James Pearson > > Eric Sandeen wrote: > > > > 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 Mon Oct 14 07:48:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 07:48: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 g9EEmmtG016988 for ; Mon, 14 Oct 2002 07:48:48 -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 JAA81018 for ; Mon, 14 Oct 2002 09:48: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 JAA90009 for ; Mon, 14 Oct 2002 09:48:42 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9EEkN502849; Mon, 14 Oct 2002 09:46:23 -0500 Message-Id: <200210141446.g9EEkN502849@jen.americas.sgi.com> Date: Mon, 14 Oct 2002 09:46:23 -0500 Subject: TAKE - merge up to 2.5.42 To: linux-xfs@oss.sgi.com X-archive-position: 960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Oct 14 07:43:35 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:129860a linux/fs/cifs/Makefile - 1.1 linux/arch/ppc/platforms/4xx/walnut.h - 1.1 linux/drivers/net/irda/donauboe.h - 1.1 linux/Documentation/DocBook/journal-api.tmpl - 1.1 linux/drivers/net/irda/donauboe.c - 1.1 linux/Documentation/DocBook/lsm.tmpl - 1.1 linux/drivers/net/de600.h - 1.1 linux/drivers/net/3c501.h - 1.1 linux/fs/cifs/README - 1.1 linux/Documentation/filesystems/cifs.txt - 1.1 linux/fs/cifs/TODO - 1.1 linux/fs/cifs/asn1.c - 1.1 linux/Documentation/kbuild/random.txt - 1.1 linux/fs/cifs/cifs_debug.c - 1.1 linux/fs/cifs/cifs_debug.h - 1.1 linux/fs/cifs/cifs_fs_sb.h - 1.1 linux/fs/cifs/cifs_unicode.c - 1.1 linux/Documentation/rpc-cache.txt - 1.1 linux/net/sunrpc/svcauth_unix.c - 1.1 linux/fs/cifs/cifs_unicode.h - 1.1 linux/fs/cifs/cifs_uniupr.h - 1.1 linux/fs/cifs/cifsfs.c - 1.1 linux/fs/nfsd/nfs4xdr.c - 1.1 linux/fs/cifs/cifsfs.h - 1.1 linux/fs/cifs/cifsglob.h - 1.1 linux/fs/cifs/cifspdu.h - 1.1 linux/fs/cifs/cifsproto.h - 1.1 linux/fs/cifs/cifssmb.c - 1.1 linux/fs/cifs/connect.c - 1.1 linux/fs/cifs/dir.c - 1.1 linux/fs/cifs/file.c - 1.1 linux/fs/cifs/inode.c - 1.1 linux/arch/alpha/kernel/systbls.S - 1.1 linux/fs/cifs/link.c - 1.1 linux/arch/alpha/lib/dbg_stackcheck.S - 1.1 linux/arch/alpha/lib/dbg_stackkill.S - 1.1 linux/fs/cifs/md4.c - 1.1 linux/fs/cifs/md5.c - 1.1 linux/fs/cifs/md5.h - 1.1 linux/fs/cifs/misc.c - 1.1 linux/fs/nfsd/nfs4proc.c - 1.1 linux/fs/ext3/hash.c - 1.1 linux/fs/cifs/AUTHORS - 1.1 linux/drivers/input/misc/m68kspkr.c - 1.1 linux/fs/cifs/netmisc.c - 1.1 linux/drivers/isdn/hardware/eicon/xdi_vers.h - 1.1 linux/drivers/isdn/hardware/eicon/xdi_msg.h - 1.1 linux/drivers/isdn/hardware/eicon/xdi_adapter.h - 1.1 linux/drivers/isdn/hardware/eicon/um_xdi.h - 1.1 linux/net/sunrpc/cache.c - 1.1 linux/drivers/isdn/hardware/eicon/um_idi.h - 1.1 linux/include/asm-i386/timer.h - 1.1 linux/fs/cifs/CHANGES - 1.1 linux/fs/cifs/transport.c - 1.1 linux/fs/cifs/smberr.h - 1.1 linux/fs/cifs/smbencrypt.c - 1.1 linux/include/asm-ppc/ibm405.h - 1.1 linux/drivers/isdn/hardware/eicon/um_idi.c - 1.1 linux/drivers/isdn/hardware/eicon/sdp_hdr.h - 1.1 linux/fs/cifs/smbdes.c - 1.1 linux/fs/cifs/ntlmssp.h - 1.1 linux/drivers/isdn/hardware/eicon/s_pri.c - 1.1 linux/fs/cifs/nterr.h - 1.1 linux/drivers/isdn/hardware/eicon/s_bri.c - 1.1 linux/arch/i386/kernel/timers/Makefile - 1.1 linux/arch/i386/kernel/timers/timer.c - 1.1 linux/arch/i386/kernel/timers/timer_cyclone.c - 1.1 linux/arch/i386/kernel/timers/timer_pit.c - 1.1 linux/arch/i386/kernel/timers/timer_tsc.c - 1.1 linux/drivers/isdn/hardware/eicon/s_4bri.c - 1.1 linux/drivers/isdn/hardware/eicon/pr_pc.h - 1.1 linux/drivers/isdn/hardware/eicon/platform.h - 1.1 linux/drivers/isdn/hardware/eicon/pkmaint.h - 1.1 linux/drivers/isdn/hardware/eicon/pc_maint.h - 1.1 linux/drivers/isdn/hardware/eicon/pc_init.h - 1.1 linux/drivers/isdn/hardware/eicon/pc.h - 1.1 linux/drivers/isdn/hardware/eicon/os_pri.h - 1.1 linux/drivers/isdn/hardware/eicon/os_pri.c - 1.1 linux/fs/cifs/nterr.c - 1.1 linux/drivers/isdn/hardware/eicon/os_capi.h - 1.1 linux/include/asm-um/topology.h - 1.1 linux/include/asm-um/xor.h - 1.1 linux/drivers/isdn/hardware/eicon/Config.help - 1.1 linux/drivers/isdn/hardware/eicon/os_bri.h - 1.1 linux/drivers/isdn/hardware/eicon/Config.in - 1.1 linux/drivers/isdn/hardware/eicon/os_bri.c - 1.1 linux/drivers/isdn/hardware/eicon/Makefile - 1.1 linux/drivers/isdn/hardware/eicon/adapter.h - 1.1 linux/drivers/isdn/hardware/eicon/os_4bri.h - 1.1 linux/drivers/isdn/hardware/eicon/os_4bri.c - 1.1 linux/drivers/isdn/hardware/eicon/mntfunc.c - 1.1 linux/drivers/isdn/hardware/eicon/mi_pc.h - 1.1 linux/drivers/isdn/hardware/eicon/message.c - 1.1 linux/drivers/isdn/hardware/eicon/mdm_msg.h - 1.1 linux/drivers/isdn/hardware/eicon/man_defs.h - 1.1 linux/drivers/isdn/hardware/eicon/maintidi.h - 1.1 linux/drivers/isdn/hardware/eicon/maintidi.c - 1.1 linux/drivers/isdn/hardware/eicon/main_if.h - 1.1 linux/drivers/isdn/hardware/eicon/kst_ifc.h - 1.1 linux/drivers/isdn/hardware/eicon/istream.c - 1.1 linux/drivers/isdn/hardware/eicon/io.h - 1.1 linux/drivers/isdn/hardware/eicon/io.c - 1.1 linux/drivers/isdn/hardware/eicon/idifunc.c - 1.1 linux/drivers/isdn/hardware/eicon/i4lididrv.h - 1.1 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.1 linux/drivers/isdn/hardware/eicon/i4l_idi.h - 1.1 linux/drivers/isdn/hardware/eicon/i4l_idi.c - 1.1 linux/drivers/isdn/hardware/eicon/capi20.h - 1.1 linux/drivers/isdn/hardware/eicon/helpers.h - 1.1 linux/drivers/isdn/hardware/eicon/entity.h - 1.1 linux/arch/ppc/configs/cedar_defconfig - 1.1 linux/drivers/isdn/hardware/eicon/capidtmf.c - 1.1 linux/drivers/isdn/hardware/eicon/dsrv_pri.h - 1.1 linux/arch/ppc/kernel/asm-offsets.c - 1.1 linux/drivers/isdn/hardware/eicon/capidtmf.h - 1.1 linux/drivers/isdn/hardware/eicon/dsrv_bri.h - 1.1 linux/drivers/isdn/hardware/eicon/dsrv4bri.h - 1.1 linux/drivers/isdn/hardware/eicon/dspdids.h - 1.1 linux/drivers/isdn/hardware/eicon/dsp_tst.h - 1.1 linux/drivers/isdn/hardware/eicon/capifunc.c - 1.1 linux/drivers/isdn/hardware/eicon/capifunc.h - 1.1 linux/drivers/isdn/hardware/eicon/dsp_defs.h - 1.1 linux/drivers/isdn/hardware/eicon/dqueue.h - 1.1 linux/drivers/isdn/hardware/eicon/dqueue.c - 1.1 linux/drivers/isdn/hardware/eicon/dlist.h - 1.1 linux/drivers/isdn/hardware/eicon/dlist.c - 1.1 linux/include/linux/nfs4.h - 1.1 linux/include/linux/nfsd/xdr4.h - 1.1 linux/arch/ppc/platforms/4xx/Makefile - 1.1 linux/arch/ppc/platforms/4xx/ash.c - 1.1 linux/arch/ppc/platforms/4xx/ash.h - 1.1 linux/arch/ppc/platforms/4xx/cedar.c - 1.1 linux/arch/ppc/platforms/4xx/cedar.h - 1.1 linux/arch/ppc/platforms/4xx/cpci405.c - 1.1 linux/arch/ppc/platforms/4xx/cpci405.h - 1.1 linux/arch/ppc/platforms/4xx/ep405.c - 1.1 linux/arch/ppc/platforms/4xx/ep405.h - 1.1 linux/arch/ppc/platforms/4xx/ibm405gp.c - 1.1 linux/arch/ppc/platforms/4xx/ibm405gp.h - 1.1 linux/arch/ppc/platforms/4xx/ibm_ocp.h - 1.1 linux/arch/ppc/platforms/4xx/ibmnp405h.c - 1.1 linux/arch/ppc/platforms/4xx/ibmnp405h.h - 1.1 linux/arch/ppc/platforms/4xx/ibmnp405l.c - 1.1 linux/arch/ppc/platforms/4xx/ibmnp405l.h - 1.1 linux/arch/ppc/platforms/4xx/ibmstb3.c - 1.1 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.1 linux/arch/ppc/platforms/4xx/ibmstb4.c - 1.1 linux/arch/ppc/platforms/4xx/ibmstb4.h - 1.1 linux/arch/ppc/platforms/4xx/redwood.c - 1.1 linux/arch/ppc/platforms/4xx/redwood.h - 1.1 linux/arch/ppc/platforms/4xx/redwood5.c - 1.1 linux/arch/ppc/platforms/4xx/redwood5.h - 1.1 linux/arch/ppc/platforms/4xx/walnut.c - 1.1 linux/drivers/isdn/hardware/eicon/debug_if.h - 1.1 linux/arch/um/include/time_user.h - 1.1 linux/drivers/isdn/hardware/eicon/capimain.c - 1.1 linux/include/linux/sunrpc/cache.h - 1.1 linux/include/linux/sunrpc/name_lookup.h - 1.1 linux/drivers/isdn/hardware/eicon/cardtype.h - 1.1 linux/arch/um/drivers/pcap_user.h - 1.1 linux/arch/um/drivers/pcap_user.c - 1.1 linux/arch/um/drivers/pcap_kern.c - 1.1 linux/drivers/isdn/hardware/eicon/cp_vers.h - 1.1 linux/drivers/isdn/hardware/eicon/dadapter.c - 1.1 linux/drivers/isdn/hardware/eicon/dadapter.h - 1.1 linux/drivers/isdn/hardware/eicon/dbgioctl.h - 1.1 linux/drivers/isdn/hardware/eicon/debug.c - 1.1 linux/drivers/isdn/hardware/eicon/divasfunc.c - 1.1 linux/drivers/isdn/hardware/eicon/divasync.h - 1.1 linux/drivers/isdn/hardware/eicon/divasproc.c - 1.1 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.1 linux/drivers/isdn/hardware/eicon/divasi.c - 1.1 linux/drivers/isdn/hardware/eicon/diva_didd.c - 1.1 linux/drivers/isdn/hardware/eicon/divamnt.c - 1.1 linux/drivers/isdn/hardware/eicon/divacapi.h - 1.1 linux/drivers/isdn/hardware/eicon/diva_pci.h - 1.1 linux/drivers/isdn/hardware/eicon/debuglib.c - 1.1 linux/drivers/isdn/hardware/eicon/diva_dma.h - 1.1 linux/drivers/isdn/hardware/eicon/diva_dma.c - 1.1 linux/drivers/isdn/hardware/eicon/dfifo.h - 1.1 linux/drivers/isdn/hardware/eicon/debuglib.h - 1.1 linux/drivers/isdn/hardware/eicon/di_defs.h - 1.1 linux/drivers/isdn/hardware/eicon/di.c - 1.1 linux/drivers/isdn/hardware/eicon/di.h - 1.1 linux/drivers/isdn/hardware/eicon/di_dbg.h - 1.1 linux/drivers/isdn/hardware/eicon/diva.h - 1.1 linux/drivers/isdn/hardware/eicon/diddfunc.c - 1.1 linux/drivers/isdn/hardware/eicon/did_vers.h - 1.1 linux/drivers/isdn/hardware/eicon/diva.c - 1.1 linux/scripts/Menuconfig - 1.16 linux/net/x25/x25_timer.c - 1.9 linux/net/x25/x25_dev.c - 1.11 linux/net/sunrpc/xprt.c - 1.34 linux/net/sunrpc/svcsock.c - 1.23 linux/net/sunrpc/svcauth.c - 1.6 linux/net/sunrpc/svc.c - 1.15 linux/net/sunrpc/sunrpc_syms.c - 1.14 linux/net/sunrpc/stats.c - 1.10 linux/net/sunrpc/pmap_clnt.c - 1.8 linux/net/sunrpc/auth_unix.c - 1.9 linux/net/sunrpc/auth_null.c - 1.9 linux/net/sunrpc/Makefile - 1.7 linux/net/socket.c - 1.43 linux/net/sched/sch_teql.c - 1.12 linux/net/sched/sch_tbf.c - 1.13 linux/net/sched/sch_sfq.c - 1.8 linux/net/sched/sch_red.c - 1.10 linux/net/sched/sch_prio.c - 1.8 linux/net/sched/sch_generic.c - 1.13 linux/net/sched/sch_fifo.c - 1.5 linux/net/sched/sch_csz.c - 1.7 linux/net/sched/sch_cbq.c - 1.14 linux/net/irda/qos.c - 1.17 linux/net/irda/irsysctl.c - 1.11 linux/net/irda/irlmp_event.c - 1.20 linux/net/irda/crc.c - 1.3 linux/net/ipv6/udp.c - 1.32 linux/net/ipv6/tcp_ipv6.c - 1.41 linux/net/ipv6/sit.c - 1.24 linux/net/ipv6/raw.c - 1.28 linux/net/ipv6/protocol.c - 1.8 linux/net/ipv6/ip6_input.c - 1.10 linux/net/ipv6/icmp.c - 1.21 linux/net/ipv6/addrconf.c - 1.28 linux/net/ipv4/tcp_timer.c - 1.25 linux/net/ipv4/tcp_ipv4.c - 1.50 linux/net/ipv4/tcp_input.c - 1.43 linux/net/ipv4/tcp.c - 1.44 linux/net/ipv4/raw.c - 1.24 linux/net/ipv4/protocol.c - 1.9 linux/net/ipv4/ipmr.c - 1.23 linux/net/ipv4/ipip.c - 1.24 linux/net/ipv4/ip_input.c - 1.17 linux/net/ipv4/ip_gre.c - 1.23 linux/net/ipv4/icmp.c - 1.32 linux/net/ipv4/af_inet.c - 1.41 linux/net/core/sock.c - 1.28 linux/net/appletalk/sysctl_net_atalk.c - 1.5 linux/net/appletalk/ddp.c - 1.24 linux/net/appletalk/aarp.c - 1.16 linux/mm/vmalloc.c - 1.45 linux/mm/swap_state.c - 1.52 linux/mm/page_alloc.c - 1.96 linux/mm/mremap.c - 1.36 linux/mm/filemap.c - 1.138 linux/mm/Makefile - 1.20 linux/kernel/sysctl.c - 1.59 linux/kernel/softirq.c - 1.31 linux/kernel/sched.c - 1.86 linux/kernel/printk.c - 1.25 linux/kernel/ksyms.c - 1.170 linux/kernel/fork.c - 1.74 linux/ipc/util.c - 1.21 linux/ipc/shm.c - 1.58 linux/ipc/sem.c - 1.22 linux/ipc/msg.c - 1.15 linux/include/net/tcp.h - 1.36 linux/include/net/sock.h - 1.35 linux/include/net/rawv6.h - 1.5 linux/include/net/raw.h - 1.5 linux/include/net/protocol.h - 1.8 linux/include/net/irda/crc.h - 1.3 linux/include/linux/ufs_fs.h - 1.17 linux/include/linux/types.h - 1.10 linux/include/linux/sunrpc/xprt.h - 1.16 linux/include/linux/sunrpc/svcsock.h - 1.8 linux/include/linux/sunrpc/svcauth.h - 1.4 linux/include/linux/sunrpc/svc.h - 1.9 linux/include/linux/sunrpc/stats.h - 1.4 linux/include/linux/sunrpc/debug.h - 1.6 linux/include/linux/smb_fs.h - 1.22 linux/include/linux/serialP.h - 1.17 linux/include/linux/qnx4_fs.h - 1.14 linux/include/linux/pci.h - 1.66 linux/include/linux/nfsd/xdr.h - 1.6 linux/include/linux/nfsd/nfsfh.h - 1.15 linux/include/linux/nfsd/nfsd.h - 1.16 linux/include/linux/nfsd/export.h - 1.15 linux/include/linux/nfsd/const.h - 1.6 linux/include/linux/nfs_fs.h - 1.27 linux/include/linux/nfs3.h - 1.5 linux/include/linux/ncp_fs.h - 1.16 linux/include/linux/msdos_fs.h - 1.23 linux/include/linux/loop.h - 1.10 linux/include/linux/lockd/bind.h - 1.5 linux/include/linux/keyboard.h - 1.4 linux/include/linux/kernel.h - 1.38 linux/include/linux/kd.h - 1.4 linux/include/linux/iso_fs.h - 1.17 linux/include/linux/isdn.h - 1.28 linux/include/linux/ipc.h - 1.7 linux/include/linux/hfs_fs.h - 1.13 linux/include/linux/hdreg.h - 1.28 linux/include/linux/genhd.h - 1.27 linux/include/linux/fs.h - 1.194 linux/include/linux/ext2_fs.h - 1.22 linux/include/linux/dcache.h - 1.28 linux/include/linux/coda_psdev.h - 1.8 linux/include/linux/coda_proc.h - 1.8 linux/include/linux/coda_linux.h - 1.16 linux/include/linux/coda_fs_i.h - 1.9 linux/include/linux/blkdev.h - 1.73 linux/include/linux/atalk.h - 1.8 linux/include/linux/affs_fs_sb.h - 1.5 linux/include/linux/adfs_fs.h - 1.9 linux/include/asm-ppc/ucontext.h - 1.6 linux/include/asm-ppc/types.h - 1.13 linux/include/asm-ppc/sigcontext.h - 1.5 linux/include/asm-ppc/semaphore.h - 1.11 linux/include/asm-ppc/pgtable.h - 1.40 linux/include/asm-ppc/hardirq.h - 1.22 linux/include/asm-m68k/q40_keyboard.h - 1.6 linux/include/asm-m68k/machdep.h - 1.8 linux/include/asm-i386/types.h - 1.5 linux/include/asm-i386/smp.h - 1.22 linux/include/asm-i386/processor.h - 1.44 linux/include/asm-i386/pgtable.h - 1.39 linux/include/asm-i386/page.h - 1.32 linux/include/asm-i386/io.h - 1.30 linux/include/asm-i386/hardirq.h - 1.25 linux/include/asm-i386/fixmap.h - 1.12 linux/include/asm-i386/byteorder.h - 1.3 linux/include/asm-alpha/unistd.h - 1.24 linux/include/asm-alpha/pal.h - 1.3 linux/fs/vfat/vfatfs_syms.c - 1.9 linux/fs/vfat/namei.c - 1.35 linux/fs/umsdos/namei.c - 1.15 linux/fs/ufs/super.c - 1.37 linux/fs/ufs/inode.c - 1.26 linux/fs/sysv/symlink.c - 1.11 linux/fs/sysv/namei.c - 1.20 linux/fs/sysv/inode.c - 1.34 linux/fs/sysv/file.c - 1.16 linux/fs/sysv/dir.c - 1.18 linux/fs/smbfs/inode.c - 1.43 linux/fs/romfs/inode.c - 1.40 linux/fs/read_write.c - 1.26 linux/fs/qnx4/inode.c - 1.38 linux/fs/proc/generic.c - 1.33 linux/fs/proc/array.c - 1.50 linux/fs/pipe.c - 1.35 linux/fs/ntfs/super.c - 1.21 linux/fs/nls/Config.in - 1.12 linux/fs/nfsd/vfs.c - 1.57 linux/fs/nfsd/nfsxdr.c - 1.17 linux/fs/nfsd/nfssvc.c - 1.26 linux/fs/nfsd/nfsproc.c - 1.27 linux/fs/nfsd/nfsfh.c - 1.46 linux/fs/nfsd/nfsctl.c - 1.35 linux/fs/nfsd/nfs3xdr.c - 1.30 linux/fs/nfsd/nfs3proc.c - 1.17 linux/fs/nfsd/lockd.c - 1.12 linux/fs/nfsd/export.c - 1.41 linux/fs/nfsd/Makefile - 1.6 linux/fs/nfs/write.c - 1.44 linux/fs/nfs/read.c - 1.36 linux/fs/nfs/proc.c - 1.17 linux/fs/nfs/nfs3xdr.c - 1.17 linux/fs/nfs/nfs2xdr.c - 1.20 linux/fs/nfs/inode.c - 1.55 linux/fs/nfs/file.c - 1.37 linux/fs/nfs/dir.c - 1.46 linux/fs/ncpfs/inode.c - 1.39 linux/fs/msdos/namei.c - 1.33 linux/fs/msdos/msdosfs_syms.c - 1.11 linux/fs/minix/inode.c - 1.37 linux/fs/lockd/svcproc.c - 1.14 linux/fs/lockd/svc.c - 1.22 linux/fs/isofs/inode.c - 1.40 linux/fs/isofs/dir.c - 1.19 linux/fs/inode.c - 1.84 linux/fs/hfs/sysdep.c - 1.8 linux/fs/hfs/super.c - 1.19 linux/fs/hfs/inode.c - 1.19 linux/fs/hfs/file_hdr.c - 1.16 linux/fs/hfs/file_cap.c - 1.15 linux/fs/hfs/file.c - 1.21 linux/fs/hfs/dir_nat.c - 1.13 linux/fs/hfs/dir_dbl.c - 1.13 linux/fs/hfs/dir_cap.c - 1.12 linux/fs/hfs/catalog.c - 1.8 linux/fs/fat/inode.c - 1.49 linux/fs/fat/file.c - 1.26 linux/fs/ext2/super.c - 1.37 linux/fs/ext2/inode.c - 1.56 linux/fs/ext2/file.c - 1.23 linux/fs/exec.c - 1.69 linux/fs/dquot.c - 1.62 linux/fs/dcache.c - 1.42 linux/fs/coda/upcall.c - 1.19 linux/fs/coda/sysctl.c - 1.18 linux/fs/coda/symlink.c - 1.15 linux/fs/coda/psdev.c - 1.24 linux/fs/coda/pioctl.c - 1.17 linux/fs/coda/inode.c - 1.28 linux/fs/coda/file.c - 1.21 linux/fs/coda/dir.c - 1.28 linux/fs/coda/coda_linux.c - 1.11 linux/fs/coda/cnode.c - 1.16 linux/fs/buffer.c - 1.138 linux/fs/autofs/symlink.c - 1.7 linux/fs/autofs/root.c - 1.20 linux/fs/autofs/inode.c - 1.15 linux/fs/autofs/init.c - 1.10 linux/fs/autofs/autofs_i.h - 1.13 linux/fs/affs/super.c - 1.27 linux/fs/affs/inode.c - 1.23 linux/fs/affs/file.c - 1.31 linux/fs/adfs/super.c - 1.25 linux/fs/adfs/inode.c - 1.28 linux/fs/Makefile - 1.70 linux/fs/Config.in - 1.99 linux/drivers/video/Config.in - 1.41 linux/drivers/sgi/char/sgiserial.c - 1.13 linux/drivers/scsi/wd7000.h - 1.7 linux/drivers/scsi/wd7000.c - 1.18 linux/drivers/scsi/wd33c93.h - 1.10 linux/drivers/scsi/t128.h - 1.6 linux/drivers/scsi/sr.c - 1.54 linux/drivers/scsi/sgiwd93.c - 1.15 linux/drivers/scsi/seagate.h - 1.5 linux/drivers/scsi/seagate.c - 1.20 linux/drivers/scsi/sd.h - 1.10 linux/drivers/scsi/sd.c - 1.74 linux/drivers/scsi/scsi_syms.c - 1.20 linux/drivers/scsi/scsi_ioctl.c - 1.24 linux/drivers/scsi/scsi.h - 1.35 linux/drivers/scsi/scsi.c - 1.61 linux/drivers/scsi/qlogicpti.h - 1.7 linux/drivers/scsi/qlogicfas.c - 1.16 linux/drivers/scsi/ppa.h - 1.11 linux/drivers/scsi/ppa.c - 1.19 linux/drivers/scsi/pas16.h - 1.5 linux/drivers/scsi/megaraid.c - 1.37 linux/drivers/scsi/inia100.c - 1.22 linux/drivers/scsi/ini9100u.c - 1.19 linux/drivers/scsi/in2000.h - 1.11 linux/drivers/scsi/in2000.c - 1.12 linux/drivers/scsi/imm.h - 1.10 linux/drivers/scsi/imm.c - 1.19 linux/drivers/scsi/ide-scsi.c - 1.46 linux/drivers/scsi/ibmmca.c - 1.18 linux/drivers/scsi/hosts.h - 1.26 linux/drivers/scsi/fdomain.h - 1.6 linux/drivers/scsi/fdomain.c - 1.23 linux/drivers/scsi/esp.h - 1.8 linux/drivers/scsi/esp.c - 1.24 linux/drivers/scsi/atp870u.c - 1.22 linux/drivers/scsi/aha152x.c - 1.32 linux/drivers/scsi/advansys.c - 1.28 linux/drivers/scsi/NCR53C9x.h - 1.7 linux/drivers/scsi/NCR53C9x.c - 1.17 linux/drivers/scsi/Makefile - 1.41 linux/drivers/scsi/Config.in - 1.33 linux/drivers/scsi/BusLogic.c - 1.18 linux/drivers/scsi/53c7xx.c - 1.19 linux/drivers/net/sgiseeq.c - 1.17 linux/drivers/net/irda/Makefile - 1.20 linux/drivers/net/irda/Config.in - 1.16 linux/drivers/net/ewrk3.c - 1.24 linux/drivers/net/depca.c - 1.21 linux/drivers/net/de600.c - 1.19 linux/drivers/net/3c59x.c - 1.38 linux/drivers/net/3c509.c - 1.35 linux/drivers/net/3c501.c - 1.21 linux/drivers/macintosh/macserial.c - 1.23 linux/drivers/isdn/pcbit/module.c - 1.9 linux/drivers/isdn/pcbit/edss1.c - 1.6 linux/drivers/isdn/pcbit/capi.c - 1.7 linux/drivers/isdn/pcbit/callbacks.c - 1.6 linux/drivers/isdn/hisax/config.c - 1.32 linux/drivers/char/synclink.c - 1.28 linux/drivers/char/specialix.c - 1.14 linux/drivers/char/serial167.c - 1.15 linux/drivers/char/rocket.c - 1.20 linux/drivers/char/riscom8.c - 1.15 linux/drivers/char/random.c - 1.33 linux/drivers/char/pty.c - 1.14 linux/drivers/char/pcxx.c - 1.16 linux/drivers/char/keyboard.c - 1.29 linux/drivers/char/isicom.c - 1.20 linux/drivers/char/esp.c - 1.19 linux/drivers/char/dn_keyb.c - 1.9 linux/drivers/char/cyclades.c - 1.24 linux/drivers/char/atarimouse.c - 1.9 linux/drivers/char/amikeyb.c - 1.8 linux/drivers/cdrom/cdrom.c - 1.48 linux/drivers/block/rd.c - 1.63 linux/drivers/block/ps2esdi.c - 1.50 linux/drivers/block/paride/pseudo.h - 1.8 linux/drivers/block/paride/pf.c - 1.31 linux/drivers/block/paride/pcd.c - 1.27 linux/drivers/block/paride/paride.c - 1.14 linux/drivers/block/loop.c - 1.70 linux/drivers/block/ll_rw_blk.c - 1.118 linux/drivers/block/genhd.c - 1.37 linux/drivers/block/floppy.c - 1.54 linux/drivers/block/Config.in - 1.39 linux/drivers/acorn/scsi/oak.c - 1.12 linux/drivers/acorn/scsi/ecoscsi.c - 1.13 linux/drivers/acorn/scsi/cumana_1.c - 1.10 linux/drivers/acorn/scsi/acornscsi.c - 1.18 linux/drivers/acorn/net/etherh.c - 1.17 linux/arch/sparc64/solaris/misc.c - 1.27 linux/arch/sparc64/mm/init.c - 1.52 linux/arch/sparc64/kernel/sys_sparc32.c - 1.60 linux/arch/sparc64/kernel/ioctl32.c - 1.58 linux/arch/sparc64/defconfig - 1.80 linux/arch/sparc64/config.in - 1.63 linux/arch/sparc/mm/sun4c.c - 1.38 linux/arch/sparc/mm/srmmu.c - 1.41 linux/arch/sparc/config.in - 1.46 linux/arch/ppc/kernel/signal.c - 1.20 linux/arch/ppc/kernel/process.c - 1.44 linux/arch/ppc/kernel/open_pic.c - 1.30 linux/arch/ppc/kernel/mk_defs.c - 1.20 linux/arch/ppc/kernel/misc.S - 1.48 linux/arch/ppc/kernel/head.S - 1.36 linux/arch/ppc/kernel/Makefile - 1.33 linux/arch/ppc/config.in - 1.60 linux/arch/ppc/Makefile - 1.31 linux/arch/mips/config.in - 1.36 linux/arch/m68k/q40/config.c - 1.16 linux/arch/m68k/mvme16x/config.c - 1.11 linux/arch/m68k/mvme147/config.c - 1.13 linux/arch/m68k/mm/memory.c - 1.13 linux/arch/m68k/mac/config.c - 1.12 linux/arch/m68k/kernel/setup.c - 1.18 linux/arch/m68k/hp300/hil.c - 1.4 linux/arch/m68k/hp300/config.c - 1.7 linux/arch/m68k/config.in - 1.34 linux/arch/m68k/bvme6000/config.c - 1.11 linux/arch/m68k/atari/joystick.c - 1.11 linux/arch/m68k/atari/config.c - 1.10 linux/arch/m68k/atari/atakeyb.c - 1.7 linux/arch/m68k/amiga/config.c - 1.15 linux/arch/i386/mm/init.c - 1.44 linux/arch/i386/math-emu/reg_mul.c - 1.4 linux/arch/i386/math-emu/reg_ld_str.c - 1.4 linux/arch/i386/math-emu/reg_divide.c - 1.4 linux/arch/i386/math-emu/reg_compare.c - 1.4 linux/arch/i386/math-emu/reg_add_sub.c - 1.3 linux/arch/i386/math-emu/poly.h - 1.6 linux/arch/i386/math-emu/fpu_system.h - 1.6 linux/arch/i386/kernel/vm86.c - 1.20 linux/arch/i386/kernel/trampoline.S - 1.7 linux/arch/i386/kernel/time.c - 1.29 linux/arch/i386/kernel/process.c - 1.58 linux/arch/i386/kernel/irq.c - 1.49 linux/arch/i386/kernel/head.S - 1.28 linux/arch/i386/kernel/apm.c - 1.53 linux/arch/i386/kernel/Makefile - 1.37 linux/arch/i386/defconfig - 1.114 linux/arch/i386/config.in - 1.95 linux/arch/i386/boot/compressed/misc.c - 1.17 linux/arch/i386/Makefile - 1.34 linux/arch/alpha/mm/fault.c - 1.18 linux/arch/alpha/lib/stxncpy.S - 1.6 linux/arch/alpha/lib/stackkill.S - 1.3 linux/arch/alpha/lib/stackcheck.S - 1.3 linux/arch/alpha/lib/Makefile - 1.19 linux/arch/alpha/kernel/setup.c - 1.31 linux/arch/alpha/kernel/process.c - 1.29 linux/arch/alpha/kernel/osf_sys.c - 1.33 linux/arch/alpha/kernel/entry.S - 1.31 linux/arch/alpha/kernel/alpha_ksyms.c - 1.36 linux/arch/alpha/kernel/Makefile - 1.25 linux/arch/alpha/config.in - 1.53 linux/arch/alpha/boot/Makefile - 1.13 linux/arch/alpha/Makefile - 1.23 linux/Rules.make - 1.33 linux/Makefile - 1.223 linux/MAINTAINERS - 1.121 linux/Documentation/networking/ip-sysctl.txt - 1.14 linux/Documentation/networking/ewrk3.txt - 1.3 linux/Documentation/filesystems/00-INDEX - 1.12 linux/Documentation/Changes - 1.57 linux/net/decnet/sysctl_net_decnet.c - 1.12 linux/net/decnet/dn_timer.c - 1.7 linux/net/decnet/dn_route.c - 1.22 linux/net/decnet/dn_nsp_in.c - 1.17 linux/net/decnet/dn_neigh.c - 1.12 linux/net/decnet/dn_dev.c - 1.15 linux/net/decnet/af_decnet.c - 1.33 linux/net/decnet/TODO - 1.9 linux/include/net/dn_route.h - 1.6 linux/include/net/dn_dev.h - 1.5 linux/include/net/dn.h - 1.9 linux/include/linux/ide.h - 1.67 linux/include/linux/efs_fs.h - 1.11 linux/fs/hpfs/super.c - 1.21 linux/fs/hpfs/inode.c - 1.22 linux/fs/hpfs/hpfs_fn.h - 1.20 linux/fs/hpfs/file.c - 1.22 linux/fs/hpfs/dentry.c - 1.4 linux/fs/efs/super.c - 1.18 linux/fs/efs/inode.c - 1.13 linux/drivers/sbus/char/aurora.c - 1.20 linux/drivers/block/blkpg.c - 1.29 linux/Documentation/networking/decnet.txt - 1.10 linux/Documentation/kernel-parameters.txt - 1.18 linux/drivers/tc/zs.c - 1.9 linux/drivers/char/dz.c - 1.17 linux/arch/mips/baget/vacserial.c - 1.12 linux/drivers/char/ppdev.c - 1.33 linux/drivers/block/cpqarray.c - 1.59 linux/include/linux/threads.h - 1.7 linux/drivers/char/raw.c - 1.31 linux/include/asm-i386/apic.h - 1.19 linux/drivers/char/sx.c - 1.26 linux/drivers/char/q40_keyb.c - 1.8 linux/drivers/char/generic_serial.c - 1.14 linux/fs/partitions/check.h - 1.9 linux/fs/partitions/check.c - 1.55 linux/drivers/pnp/isapnp_proc.c - 1.16 linux/drivers/pnp/isapnp.c - 1.31 linux/Documentation/isapnp.txt - 1.6 linux/drivers/atm/zatm.c - 1.15 linux/drivers/atm/nicstar.c - 1.19 linux/drivers/atm/horizon.c - 1.14 linux/drivers/atm/eni.c - 1.19 linux/drivers/atm/ambassador.c - 1.18 linux/drivers/atm/Makefile - 1.20 linux/net/sched/sch_atm.c - 1.8 linux/net/atm/proc.c - 1.17 linux/net/atm/mpoa_proc.c - 1.10 linux/net/atm/lec.c - 1.16 linux/arch/ppc/kernel/head_8xx.S - 1.19 linux/arch/ppc/kernel/entry.S - 1.30 linux/drivers/scsi/ips.h - 1.15 linux/drivers/scsi/ips.c - 1.30 linux/net/irda/parameters.c - 1.12 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.14 linux/net/irda/ircomm/ircomm_tty.c - 1.25 linux/net/irda/ircomm/ircomm_param.c - 1.13 linux/include/net/irda/ircomm_tty.h - 1.12 linux/include/math-emu/soft-fp.h - 1.4 linux/include/math-emu/op-1.h - 1.5 linux/drivers/pcmcia/tcic.c - 1.17 linux/drivers/pcmcia/i82365.c - 1.27 linux/fs/udf/file.c - 1.30 linux/fs/udf/dir.c - 1.21 linux/fs/udf/inode.c - 1.34 linux/fs/udf/namei.c - 1.25 linux/fs/udf/super.c - 1.34 linux/fs/udf/symlink.c - 1.18 linux/fs/udf/udf_sb.h - 1.9 linux/drivers/sbus/char/uctrl.c - 1.15 linux/Documentation/filesystems/proc.txt - 1.12 linux/drivers/net/wan/cycx_drv.c - 1.7 linux/drivers/net/tokenring/olympic.h - 1.10 linux/drivers/net/tokenring/olympic.c - 1.23 linux/drivers/net/tokenring/ibmtr.c - 1.21 linux/include/linux/pci_ids.h - 1.77 linux/drivers/scsi/sim710.scr - 1.2 linux/drivers/net/wan/z85230.c - 1.12 linux/drivers/net/wan/cycx_x25.c - 1.16 linux/drivers/scsi/sim710.c - 1.12 linux/drivers/video/tdfxfb.c - 1.24 linux/drivers/scsi/sim710.h - 1.6 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.17 linux/mm/bootmem.c - 1.23 linux/fs/proc/proc_misc.c - 1.45 linux/fs/bfs/inode.c - 1.28 linux/fs/bfs/file.c - 1.24 linux/drivers/pci/gen-devlist.c - 1.9 linux/include/asm-ppc/pgalloc.h - 1.14 linux/arch/ppc/kernel/head_4xx.S - 1.10 linux/mm/numa.c - 1.15 linux/include/linux/mmzone.h - 1.30 linux/include/linux/agp_backend.h - 1.21 linux/drivers/net/aironet4500_proc.c - 1.13 linux/drivers/net/aironet4500_card.c - 1.18 linux/drivers/net/aironet4500.h - 1.12 linux/kernel/timer.c - 1.33 linux/drivers/pcmcia/yenta.c - 1.34 linux/fs/cramfs/inode.c - 1.32 linux/include/linux/input.h - 1.22 linux/drivers/telephony/ixj.c - 1.24 linux/net/sched/sch_ingress.c - 1.10 linux/drivers/pnp/quirks.c - 1.9 linux/net/sched/sch_gred.c - 1.10 linux/net/sched/sch_dsmark.c - 1.9 linux/arch/i386/kernel/apic.c - 1.36 linux/arch/i386/kernel/mpparse.c - 1.28 linux/drivers/char/moxa.c - 1.15 linux/drivers/char/mxser.c - 1.20 linux/include/asm-i386/mpspec.h - 1.11 linux/drivers/scsi/scsi_scan.c - 1.31 linux/drivers/scsi/3w-xxxx.c - 1.22 linux/Documentation/DMA-mapping.txt - 1.17 linux/fs/autofs4/init.c - 1.7 linux/fs/autofs4/autofs_i.h - 1.10 linux/fs/autofs4/symlink.c - 1.4 linux/fs/autofs4/root.c - 1.17 linux/fs/autofs4/inode.c - 1.15 linux/drivers/atm/iphase.c - 1.14 linux/drivers/acorn/char/pcf8583.c - 1.6 linux/arch/ia64/ia32/sys_ia32.c - 1.31 linux/arch/ia64/defconfig - 1.21 linux/arch/ia64/config.in - 1.37 linux/arch/ia64/kernel/setup.c - 1.19 linux/drivers/scsi/qla1280.c - 1.20 linux/include/linux/raid/raid0.h - 1.4 linux/include/linux/raid/md_k.h - 1.28 linux/include/linux/raid/md.h - 1.20 linux/drivers/scsi/sun3_NCR5380.c - 1.6 linux/drivers/char/amiserial.c - 1.14 linux/fs/devfs/base.c - 1.45 linux/fs/lockd/svc4proc.c - 1.10 linux/drivers/net/ioc3-eth.c - 1.20 linux/arch/mips64/defconfig - 1.21 linux/drivers/atm/fore200e.c - 1.17 linux/arch/mips64/config.in - 1.26 linux/drivers/net/bonding.c - 1.15 linux/lib/brlock.c - 1.7 linux/drivers/ide/ide.c - 1.72 linux/drivers/ide/ide-tape.c - 1.37 linux/drivers/ide/ide-proc.c - 1.24 linux/drivers/ide/ide-probe.c - 1.42 linux/drivers/ide/ide-floppy.c - 1.37 linux/drivers/ide/ide-dma.c - 1.32 linux/drivers/ide/ide-disk.c - 1.50 linux/drivers/ide/ide-cd.c - 1.50 linux/drivers/ide/Makefile - 1.31 linux/drivers/ide/Config.in - 1.35 linux/Documentation/DocBook/Makefile - 1.37 linux/Documentation/DocBook/kernel-api.tmpl - 1.23 linux/fs/nfs/flushd.c - 1.13 linux/drivers/scsi/dmx3191d.h - 1.4 linux/drivers/char/wdt_pci.c - 1.13 linux/Documentation/DocBook/parportbook.tmpl - 1.9 linux/include/linux/nfs_xdr.h - 1.11 linux/fs/ramfs/inode.c - 1.32 linux/fs/nfs/nfs3proc.c - 1.15 linux/drivers/net/wan/lmc/lmc_debug.c - 1.2 linux/drivers/net/pppoe.c - 1.22 linux/arch/s390/Makefile - 1.12 linux/arch/s390/config.in - 1.15 linux/arch/s390/defconfig - 1.15 linux/arch/s390/kernel/Makefile - 1.10 linux/arch/s390/kernel/entry.S - 1.21 linux/drivers/s390/misc/chandev.c - 1.12 linux/drivers/s390/char/con3215.c - 1.10 linux/drivers/s390/block/dasd_eckd.c - 1.11 linux/drivers/s390/block/dasd.c - 1.31 linux/fs/xfs/linux/xfs_super.h - 1.30 linux/kdb/modules/kdbm_pg.c - 1.65 linux/drivers/usb/serial/keyspan.c - 1.35 linux/drivers/acpi/tables/tbxface.c - 1.12 linux/drivers/acpi/namespace/nsutils.c - 1.13 linux/fs/jffs/inode-v23.c - 1.33 linux/fs/jffs/intrep.c - 1.17 linux/drivers/acpi/events/evevent.c - 1.15 linux/drivers/acpi/dispatcher/dswscope.c - 1.9 linux/drivers/acpi/dispatcher/dswload.c - 1.16 linux/drivers/acpi/dispatcher/dsutils.c - 1.13 linux/drivers/acpi/dispatcher/dsobject.c - 1.17 linux/drivers/acpi/dispatcher/dsfield.c - 1.11 linux/include/linux/gameport.h - 1.9 linux/include/linux/serio.h - 1.7 linux/net/ipv4/tcp_minisocks.c - 1.17 linux/fs/nfs/unlink.c - 1.7 linux/drivers/media/video/cpia_usb.c - 1.13 linux/drivers/media/video/cpia.h - 1.4 linux/drivers/media/radio/radio-zoltrix.c - 1.10 linux/drivers/media/radio/radio-cadet.c - 1.10 linux/drivers/isdn/eicon/Divas_mod.c - 1.8 linux/drivers/input/mousedev.c - 1.15 linux/drivers/input/joydev.c - 1.13 linux/drivers/input/input.c - 1.15 linux/drivers/input/evdev.c - 1.14 linux/drivers/md/raid1.c - 1.26 linux/drivers/md/raid5.c - 1.36 linux/Documentation/SubmittingDrivers - 1.7 linux/arch/i386/kernel/bluesmoke.c - 1.27 linux/drivers/acpi/include/acconfig.h - 1.18 linux/drivers/acpi/include/acmacros.h - 1.13 linux/drivers/acpi/include/acnamesp.h - 1.12 linux/drivers/acpi/namespace/nsdump.c - 1.12 linux/drivers/block/cciss.c - 1.46 linux/drivers/block/cciss.h - 1.16 linux/drivers/macintosh/adbhid.c - 1.8 linux/drivers/macintosh/mac_hid.c - 1.7 linux/drivers/md/Makefile - 1.10 linux/drivers/md/linear.c - 1.14 linux/drivers/md/md.c - 1.60 linux/drivers/md/raid0.c - 1.13 linux/drivers/scsi/cpqfcTSstructs.h - 1.11 linux/fs/dnotify.c - 1.7 linux/net/irda/irsyms.c - 1.9 linux/arch/i386/kernel/dmi_scan.c - 1.21 linux/include/asm-m68k/sun3_pgalloc.h - 1.8 linux/arch/parisc/config.in - 1.11 linux/mm/shmem.c - 1.48 linux/drivers/atm/firestream.c - 1.12 linux/fs/reiserfs/super.c - 1.29 linux/drivers/acpi/acpi_ksyms.c - 1.12 linux/fs/reiserfs/resize.c - 1.9 linux/fs/reiserfs/prints.c - 1.18 linux/fs/reiserfs/journal.c - 1.36 linux/fs/reiserfs/inode.c - 1.35 linux/include/linux/reiserfs_fs.h - 1.34 linux/include/asm-s390x/debug.h - 1.7 linux/arch/s390x/kernel/linux32.c - 1.16 linux/arch/s390x/kernel/ioctl32.c - 1.6 linux/arch/cris/mm/init.c - 1.10 linux/drivers/s390/net/fsm.c - 1.4 linux/drivers/s390/net/ctcmain.c - 1.9 linux/arch/s390x/kernel/entry.S - 1.15 linux/arch/s390x/kernel/Makefile - 1.10 linux/arch/s390x/defconfig - 1.14 linux/arch/s390x/config.in - 1.10 linux/drivers/s390/block/dasd_fba.c - 1.9 linux/drivers/s390/block/dasd_diag.c - 1.9 linux/include/asm-s390/debug.h - 1.7 linux/arch/s390x/Makefile - 1.13 linux/drivers/scsi/aic7xxx_old/aic7xxx_proc.c - 1.4 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.4 linux/drivers/scsi/aic7xxx_old.c - 1.22 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.18 linux/drivers/char/machzwd.c - 1.10 linux/drivers/s390/char/ctrlchar.c - 1.5 linux/drivers/s390/char/tuball.c - 1.7 linux/drivers/s390/char/tubfs.c - 1.7 linux/drivers/s390/char/tubio.h - 1.7 linux/drivers/s390/char/tubtty.c - 1.8 linux/drivers/s390/char/tubttybld.c - 1.3 linux/drivers/net/gt96100eth.h - 1.4 linux/drivers/net/gt96100eth.c - 1.6 linux/Documentation/s390/3270.ChangeLog - 1.2 linux/drivers/char/qtronix.c - 1.4 linux/arch/arm/mach-footbridge/mm.c - 1.3 linux/fs/freevxfs/vxfs_super.c - 1.12 linux/fs/freevxfs/vxfs_subr.c - 1.8 linux/drivers/net/wireless/orinoco_cs.c - 1.12 linux/fs/freevxfs/vxfs.h - 1.3 linux/net/bluetooth/af_bluetooth.c - 1.7 linux/drivers/mtd/nftlcore.c - 1.26 linux/drivers/acpi/executer/exstore.c - 1.11 linux/drivers/acpi/utilities/utmisc.c - 1.9 linux/drivers/acpi/include/acutils.h - 1.10 linux/drivers/acpi/executer/exstorob.c - 1.6 linux/drivers/acpi/executer/exconvrt.c - 1.9 linux/drivers/acpi/executer/excreate.c - 1.8 linux/drivers/acpi/executer/exdump.c - 1.11 linux/drivers/acpi/executer/exresnte.c - 1.11 linux/drivers/acpi/executer/exresop.c - 1.11 linux/drivers/acorn/char/mouse_ps2.c - 1.6 linux/drivers/usb/serial/pl2303.c - 1.22 linux/drivers/isdn/tpam/tpam_nco.c - 1.3 linux/drivers/isdn/tpam/tpam_main.c - 1.8 linux/drivers/isdn/tpam/tpam_commands.c - 1.5 linux/fs/sysv/itree.c - 1.9 linux/fs/sysv/super.c - 1.13 linux/arch/ppc/mm/hashtable.S - 1.8 linux/drivers/media/video/zoran_procfs.c - 1.2 linux/drivers/media/video/zr36067.c - 1.9 linux/drivers/char/w83877f_wdt.c - 1.8 linux/drivers/message/fusion/linux_compat.h - 1.4 linux/drivers/ieee1394/sbp2.c - 1.13 linux/include/linux/cramfs_fs_sb.h - 1.3 linux/fs/partitions/ldm.c - 1.8 linux/drivers/s390/block/dasd_int.h - 1.9 linux/drivers/net/irda/vlsi_ir.c - 1.12 linux/include/net/irda/vlsi_ir.h - 1.3 linux/arch/ppc/mm/ppc_mmu.c - 1.6 linux/drivers/net/ns83820.c - 1.16 linux/fs/jffs2/background.c - 1.13 linux/fs/jffs2/super.c - 1.14 linux/drivers/md/multipath.c - 1.15 linux/scripts/mkspec - 1.3 linux/lib/rbtree.c - 1.4 linux/include/linux/rbtree.h - 1.3 linux/arch/i386/kernel/nmi.c - 1.8 linux/drivers/mtd/devices/blkmtd.c - 1.15 linux/include/asm-i386/smpboot.h - 1.2 linux/drivers/message/i2o/i2o_scsi.h - 1.3 linux/drivers/message/i2o/i2o_scsi.c - 1.8 linux/drivers/message/i2o/i2o_proc.c - 1.5 linux/drivers/message/i2o/i2o_core.c - 1.7 linux/drivers/message/i2o/i2o_block.c - 1.24 linux/drivers/atm/lanai.c - 1.4 linux/drivers/acpi/executer/exoparg2.c - 1.8 linux/fs/jbd/journal.c - 1.16 linux/fs/ext3/file.c - 1.7 linux/fs/ext3/ialloc.c - 1.15 linux/fs/ext3/inode.c - 1.24 linux/fs/ext3/namei.c - 1.12 linux/fs/ext3/super.c - 1.24 linux/include/linux/jbd.h - 1.10 linux/include/linux/ext3_jbd.h - 1.5 linux/include/linux/ext3_fs_sb.h - 1.4 linux/include/linux/ext3_fs.h - 1.10 linux/fs/jbd/revoke.c - 1.9 linux/fs/jbd/transaction.c - 1.12 linux/fs/nfs/pagelist.c - 1.7 linux/fs/jbd/commit.c - 1.8 linux/fs/ext3/dir.c - 1.6 linux/fs/ext3/Makefile - 1.4 linux/include/linux/bio.h - 1.16 linux/fs/bio.c - 1.20 linux/include/linux/device.h - 1.19 linux/include/linux/gfp.h - 1.6 linux/drivers/ide/ide-taskfile.c - 1.23 linux/arch/alpha/Config.help - 1.7 linux/arch/i386/Config.help - 1.16 linux/fs/Config.help - 1.21 linux/drivers/block/Config.help - 1.3 linux/drivers/char/Config.help - 1.12 linux/drivers/ide/Config.help - 1.17 linux/drivers/net/irda/Config.help - 1.4 linux/drivers/net/mii.c - 1.6 linux/drivers/base/core.c - 1.16 linux/drivers/pnp/pnpbios_proc.c - 1.5 linux/drivers/input/joystick/gf2k.c - 1.4 linux/drivers/input/joystick/analog.c - 1.5 linux/drivers/input/joystick/adi.c - 1.5 linux/drivers/input/joystick/a3d.c - 1.4 linux/drivers/input/gameport/ns558.c - 1.4 linux/drivers/input/gameport/gameport.c - 1.5 linux/drivers/input/gameport/emu10k1-gp.c - 1.5 linux/drivers/input/joystick/magellan.c - 1.5 linux/drivers/input/joystick/spaceball.c - 1.4 linux/drivers/input/joystick/spaceorb.c - 1.4 linux/drivers/input/joystick/stinger.c - 1.4 linux/drivers/input/joystick/warrior.c - 1.4 linux/drivers/input/serio/serio.c - 1.6 linux/sound/oss/vwsnd.c - 1.4 linux/sound/oss/vidc.c - 1.3 linux/arch/ppc/configs/ceder_defconfig - 1.4 linux/sound/oss/os.h - 1.2 linux/sound/oss/opl3sa2.c - 1.3 linux/arch/ppc/kernel/iSeries_head.S - 1.6 linux/arch/ppc/kernel/iSeries_misc.S - 1.5 linux/sound/oss/maestro3.c - 1.5 linux/arch/ppc/platforms/Makefile - 1.6 linux/arch/ppc/platforms/ash.c - 1.2 linux/arch/ppc/platforms/ash.h - 1.2 linux/arch/ppc/platforms/ceder.c - 1.2 linux/arch/ppc/platforms/ceder.h - 1.2 linux/arch/ppc/platforms/cpci405.c - 1.2 linux/arch/ppc/platforms/cpci405.h - 1.2 linux/arch/ppc/platforms/ep405.c - 1.5 linux/arch/ppc/platforms/ep405.h - 1.3 linux/arch/ppc/platforms/ibm405.h - 1.3 linux/arch/ppc/platforms/ibm405gp.c - 1.2 linux/arch/ppc/platforms/ibm405gp.h - 1.3 linux/arch/ppc/platforms/ibm_ocp.h - 1.3 linux/arch/ppc/platforms/ibmnp405h.c - 1.2 linux/arch/ppc/platforms/ibmnp405h.h - 1.2 linux/arch/ppc/platforms/ibmnp405l.c - 1.2 linux/arch/ppc/platforms/ibmnp405l.h - 1.2 linux/arch/ppc/platforms/ibmstb3.c - 1.2 linux/arch/ppc/platforms/ibmstb3.h - 1.2 linux/arch/ppc/platforms/ibmstb4.c - 1.2 linux/arch/ppc/platforms/ibmstb4.h - 1.2 linux/arch/ppc/platforms/redwood.c - 1.3 linux/arch/ppc/platforms/redwood.h - 1.2 linux/arch/ppc/platforms/redwood5.c - 1.2 linux/arch/ppc/platforms/redwood5.h - 1.2 linux/arch/ppc/platforms/walnut.c - 1.3 linux/arch/ppc/platforms/walnut.h - 1.3 linux/sound/oss/cs46xx.c - 1.5 linux/arch/x86_64/config.in - 1.12 linux/arch/x86_64/defconfig - 1.11 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.8 linux/arch/x86_64/ia32/sys_ia32.c - 1.7 linux/arch/x86_64/mm/init.c - 1.7 linux/sound/oss/bin2hex.c - 1.2 linux/sound/oss/aedsp16.c - 1.2 linux/sound/isa/opl3sa2.c - 1.9 linux/sound/isa/als100.c - 1.6 linux/arch/ppc64/config.in - 1.11 linux/arch/ppc64/defconfig - 1.9 linux/arch/ppc64/kernel/ioctl32.c - 1.7 linux/arch/ppc64/kernel/sys_ppc32.c - 1.9 linux/drivers/net/e1000/e1000_main.c - 1.12 linux/fs/jfs/inode.c - 1.16 linux/fs/jfs/jfs_incore.h - 1.12 linux/fs/jfs/super.c - 1.16 linux/fs/jffs2/os-linux.h - 1.4 linux/kernel/futex.c - 1.11 linux/fs/libfs.c - 1.7 linux/lib/radix-tree.c - 1.6 linux/drivers/net/tc35815.c - 1.5 linux/drivers/ide/ide-tcq.c - 1.4 linux/include/asm-i386/tlbflush.h - 1.4 linux/drivers/usb/class/audio.c - 1.7 linux/drivers/usb/core/hub.c - 1.13 linux/drivers/usb/core/inode.c - 1.9 linux/drivers/usb/input/hid-core.c - 1.9 linux/drivers/usb/core/usb.c - 1.19 linux/drivers/base/power.c - 1.5 linux/drivers/usb/input/hid-input.c - 1.4 linux/drivers/usb/input/wacom.c - 1.5 linux/include/linux/radix-tree.h - 1.3 linux/fs/minix/minix.h - 1.3 linux/drivers/isdn/i4l/isdn_ttyfax.c - 1.3 linux/drivers/isdn/i4l/isdn_tty.c - 1.6 linux/drivers/isdn/i4l/isdn_net.h - 1.8 linux/drivers/isdn/i4l/isdn_net.c - 1.8 linux/drivers/isdn/i4l/isdn_concap.c - 1.4 linux/drivers/isdn/i4l/isdn_common.h - 1.5 linux/drivers/isdn/i4l/isdn_common.c - 1.9 linux/fs/exportfs/expfs.c - 1.7 linux/arch/ia64/hp/sim/simserial.c - 1.6 linux/drivers/isdn/hardware/Makefile - 1.4 linux/drivers/isdn/hardware/Config.in - 1.3 linux/drivers/isdn/capi/capifs.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.3 linux/fs/ntfs/ntfs.h - 1.6 linux/drivers/char/pcmcia/synclink_cs.c - 1.4 linux/drivers/block/umem.c - 1.12 linux/arch/i386/pci/fixup.c - 1.4 linux/arch/i386/pci/irq.c - 1.3 linux/fs/sysv/sysv.h - 1.3 linux/arch/ppc/kernel/asm-offsets.head - 1.2 linux/arch/i386/pci/pci.h - 1.4 linux/init/Makefile - 1.8 linux/kernel/suspend.c - 1.16 linux/include/asm-generic/siginfo.h - 1.3 linux/drivers/usb/host/hc_sl811.c - 1.3 linux/fs/bfs/bfs.h - 1.2 linux/fs/mpage.c - 1.11 linux/drivers/acpi/pci_irq.c - 1.7 linux/drivers/acpi/thermal.c - 1.7 linux/drivers/acpi/processor.c - 1.8 linux/drivers/acpi/osl.c - 1.7 linux/drivers/acpi/utils.c - 1.4 linux/drivers/isdn/hisax/ipacx.c - 1.5 linux/scripts/fixdep.c - 1.6 linux/drivers/s390/sysinfo.c - 1.2 linux/drivers/s390/net/lcs.c - 1.4 linux/arch/i386/kernel/cpu/proc.c - 1.3 linux/arch/i386/kernel/cpu/intel.c - 1.8 linux/drivers/s390/cio/cio.c - 1.3 linux/arch/i386/kernel/cpu/cyrix.c - 1.3 linux/drivers/s390/block/dasd_genhd.c - 1.10 linux/arch/i386/kernel/cpu/amd.c - 1.5 linux/net/llc/llc_mac.c - 1.8 linux/net/llc/llc_c_ac.c - 1.8 linux/drivers/scsi/sim710_d.h_shipped - 1.2 linux/drivers/input/keyboard/atkbd.c - 1.7 linux/drivers/input/tsdev.c - 1.4 linux/drivers/input/touchscreen/gunze.c - 1.3 linux/drivers/input/serio/i8042.h - 1.4 linux/drivers/input/serio/i8042.c - 1.6 linux/drivers/input/mouse/sermouse.c - 1.3 linux/drivers/input/mouse/rpcmouse.c - 1.4 linux/drivers/input/mouse/psmouse.c - 1.7 linux/drivers/input/mouse/logibm.c - 1.3 linux/drivers/input/mouse/inport.c - 1.3 linux/drivers/input/keyboard/xtkbd.c - 1.4 linux/drivers/input/keyboard/sunkbd.c - 1.6 linux/drivers/input/keyboard/amikbd.c - 1.4 linux/drivers/input/joystick/twidjoy.c - 1.3 linux/include/linux/uinput.h - 1.3 linux/drivers/input/keyboard/newtonkbd.c - 1.4 linux/drivers/input/serio/i8042-io.h - 1.4 linux/drivers/input/serio/i8042-ppcio.h - 1.3 linux/drivers/input/touchscreen/h3600_ts_input.c - 1.3 linux/drivers/usb/input/powermate.c - 1.5 linux/security/dummy.c - 1.3 linux/security/capability.c - 1.3 linux/drivers/serial/core.c - 1.3 linux/drivers/char/agp/agp.c - 1.4 linux/drivers/char/agp/i8x0-agp.c - 1.2 linux/drivers/serial/8250_pci.c - 1.3 linux/drivers/serial/8250.c - 1.7 linux/arch/i386/mm/pgtable.c - 1.4 linux/include/linux/security.h - 1.3 linux/arch/ppc64/kernel/rtas_flash.c - 1.3 linux/drivers/base/fs/device.c - 1.3 linux/drivers/input/misc/uinput.c - 1.2 linux/drivers/input/misc/Makefile - 1.3 linux/drivers/input/misc/Config.in - 1.3 linux/fs/aio.c - 1.6 linux/arch/alpha/vmlinux.lds.S - 1.2 linux/include/linux/aio.h - 1.3 linux/net/sctp/protocol.c - 1.5 linux/include/net/sctp/sctp.h - 1.4 linux/net/sctp/input.c - 1.3 linux/net/sctp/ipv6.c - 1.3 linux/net/sctp/sm_sideeffect.c - 1.5 linux/net/sctp/sm_statetable.c - 1.3 linux/drivers/input/serio/i8042-sparcio.h - 1.2 linux/fs/xfs/linux/xfs_aops.c - 1.14 linux/arch/i386/mm/discontig.c - 1.4 linux/arch/um/ptproxy/Makefile - 1.3 linux/drivers/ide/pci/via82cxxx.c - 1.4 linux/drivers/ide/pci/trm290.c - 1.5 linux/drivers/ide/pci/slc90e66.c - 1.4 linux/drivers/ide/pci/sl82c105.c - 1.5 linux/drivers/ide/pci/sis5513.c - 1.4 linux/drivers/ide/pci/siimage.c - 1.4 linux/drivers/ide/pci/serverworks.c - 1.4 linux/drivers/ide/pci/rz1000.c - 1.4 linux/drivers/ide/pci/piix.c - 1.4 linux/drivers/ide/pci/pdcadma.c - 1.4 linux/drivers/ide/pci/pdc202xx_old.c - 1.4 linux/drivers/ide/pci/pdc202xx_new.c - 1.4 linux/drivers/ide/pci/opti621.c - 1.4 linux/drivers/ide/pci/nvidia.c - 1.4 linux/drivers/ide/pci/ns87415.c - 1.4 linux/drivers/ide/pci/it8172.c - 1.4 linux/drivers/ide/pci/hpt366.c - 1.4 linux/drivers/ide/pci/hpt34x.c - 1.4 linux/drivers/ide/pci/generic.c - 1.4 linux/drivers/ide/pci/cy82c693.c - 1.6 linux/drivers/ide/pci/cs5530.c - 1.4 linux/drivers/ide/pci/cmd64x.c - 1.4 linux/drivers/ide/pci/amd74xx.c - 1.4 linux/drivers/ide/pci/alim15x3.c - 1.4 linux/drivers/ide/pci/aec62xx.c - 1.4 linux/drivers/ide/legacy/pdc4030.c - 1.3 linux/drivers/ide/legacy/hd.c - 1.7 linux/arch/um/Makefile - 1.4 linux/arch/um/config_net.in - 1.2 linux/arch/um/defconfig - 1.3 linux/arch/um/drivers/Makefile - 1.3 linux/arch/um/drivers/chan_kern.c - 1.2 linux/arch/um/drivers/daemon_kern.c - 1.2 linux/arch/um/drivers/daemon_kern.h - 1.2 linux/arch/um/drivers/line.c - 1.2 linux/arch/um/drivers/mcast.h - 1.2 linux/arch/um/drivers/mcast_kern.c - 1.2 linux/arch/um/drivers/mcast_kern.h - 1.2 linux/arch/um/drivers/mconsole_kern.c - 1.2 linux/arch/um/drivers/net_kern.c - 1.2 linux/arch/um/drivers/net_user.c - 1.2 linux/arch/um/drivers/port_kern.c - 1.2 linux/arch/um/drivers/port_user.c - 1.2 linux/arch/um/drivers/slip.h - 1.2 linux/arch/um/drivers/slip_kern.c - 1.2 linux/arch/um/drivers/slip_kern.h - 1.2 linux/arch/um/drivers/ubd_kern.c - 1.4 linux/arch/um/include/2_5compat.h - 1.2 linux/arch/um/include/chan_kern.h - 1.2 linux/arch/um/include/kern.h - 1.2 linux/arch/um/include/line.h - 1.2 linux/arch/um/include/net_kern.h - 1.2 linux/arch/um/include/net_user.h - 1.2 linux/arch/um/include/sysdep-ppc/sigcontext.h - 1.2 linux/arch/um/include/user_util.h - 1.3 linux/arch/um/kernel/Makefile - 1.4 linux/arch/um/kernel/irq_user.c - 1.2 linux/arch/um/kernel/mem.c - 1.3 linux/arch/um/kernel/process.c - 1.2 linux/arch/um/kernel/process_kern.c - 1.3 linux/arch/um/kernel/signal_kern.c - 1.2 linux/arch/um/kernel/time.c - 1.2 linux/arch/um/kernel/time_kern.c - 1.2 linux/arch/um/kernel/tlb.c - 1.3 linux/arch/um/kernel/trap_user.c - 1.2 linux/arch/um/os-Linux/drivers/etap_kern.h - 1.2 linux/arch/um/os-Linux/drivers/ethertap_kern.c - 1.2 linux/arch/um/os-Linux/drivers/tuntap.h - 1.2 linux/arch/um/os-Linux/drivers/tuntap_kern.c - 1.2 linux/arch/um/os-Linux/drivers/tuntap_kern.h - 1.2 linux/arch/um/os-Linux/file.c - 1.2 linux/arch/um/sys-i386/Makefile - 1.3 linux/include/asm-um/pgtable.h - 1.3 linux/arch/um/util/Makefile - 1.2 linux/drivers/char/vt_ioctl.c - 1.2 linux/arch/s390x/vmlinux.lds.S - 1.4 linux/arch/ppc/vmlinux.lds.S - 1.2 linux/arch/s390/vmlinux.lds.S - 1.4 linux/drivers/acpi/blacklist.c - 1.2 linux/drivers/acpi/sleep.c - 1.2 linux/arch/i386/kernel/reboot.c - 1.2 linux/drivers/base/hotplug.c - 1.4 linux/drivers/usb/core/driverfs.c - 1.2 linux/net/llc/llc_proc.c - 1.2 linux/net/ipx/ipx_proc.c - 1.2 linux/drivers/usb/misc/usbtest.c - 1.2 linux/drivers/scsi/aacraid/Makefile - 1.2 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.2 linux/net/bluetooth/rfcomm/tty.c - 1.2 linux/net/bluetooth/rfcomm/sock.c - 1.2 linux/net/bluetooth/rfcomm/core.c - 1.2 linux/include/net/bluetooth/rfcomm.h - 1.2 linux/net/appletalk/atalk_proc.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 14 09:59:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 09:59:23 -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 g9EGxEtG002636 for ; Mon, 14 Oct 2002 09:59:15 -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 1818YY-0003GJ-00; Mon, 14 Oct 2002 17:59:02 +0100 Message-ID: <3DAAF7D6.9B8EEADC@moving-picture.com> Date: Mon, 14 Oct 2002 17:59:02 +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: 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: 961 X-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 Thanks, that seems to compile OK. However, I have a couple of questions: When I was looking through the CVS history for xfs_log_recover.c, I noticed this (similar) one line change was after a previous bigger change to handle read-only mounts - does XFS 1.1 need something similar as well? Also, when I boot the system from CD/floppy in rescue mode and attempt to mount the root file system, I get the oops described below - but in this case the mount is mounting read-write - so I'm a bit confused to as why this read-only mount fix will help? Thanks James Pearson Eric Sandeen wrote: > > Whoops, sorry, that changed since 1.1. > > Try this, then... > > if (!is_read_only(log->l_mp->m_logdev)) { > error = xlog_clear_stale_blocks(log, tail_lsn); > } > > On Mon, 14 Oct 2002, James Pearson wrote: > > > Unfortunately it doesn't work - I get (with XFS 1.1): > > > > xfs_log_recover.c: In function `xlog_find_tail': > > xfs_log_recover.c:841: structure has no member named `m_logdev_targp' > > > > I had a quick look through the source of v1.1 and the recent 2.4.19 > > patch - but got lost ... > > > > James Pearson > > > > Eric Sandeen wrote: > > > > > > 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 Mon Oct 14 10:00:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 10:00:18 -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 g9EH0FtG002981 for ; Mon, 14 Oct 2002 10:00:15 -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 KAA08146 for ; Mon, 14 Oct 2002 10:00:14 -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 g9EGwF1D019975 for ; Mon, 14 Oct 2002 18:58:15 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9EGwFbd019966 for linux-xfs@oss.sgi.com; Mon, 14 Oct 2002 18:58:15 +0200 Date: Mon, 14 Oct 2002 18:58:15 +0200 Message-Id: <200210141658.g9EGwFbd019966@lab343.munich.sgi.com> Subject: TAKE - VMAP() prototype change To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 963 X-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 Revert VMAP() to the old IRIX prototype. Vnode and Linux inode are closely tied together nowdays so that we don't have to pass in the Linux inode separately. Date: Mon Oct 14 09:58: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:129878a linux/fs/xfs/xfs_quota_priv.h - 1.23 linux/fs/xfs/xfs_rtalloc.c - 1.80 linux/fs/xfs/xfs_qm_syscalls.c - 1.69 linux/fs/xfs/xfs_vfsops.c - 1.390 linux/fs/xfs/xfs_mount.c - 1.305 linux/fs/xfs/xfs_inode.c - 1.355 linux/fs/xfs/linux/xfs_vnode.c - 1.100 - Adjust for new old VMAP() calling convention. linux/fs/xfs/linux/xfs_vnode.h - 1.67 - Revert VMAP() to the old IRIX prototype. From owner-linux-xfs@oss.sgi.com Mon Oct 14 10:00:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 10:00:18 -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 g9EH0FtG002980 for ; Mon, 14 Oct 2002 10:00:15 -0700 Received: from rock.csd.sgi.com (rock.csd.sgi.com [130.62.75.10]) 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 KAA06612 for ; Mon, 14 Oct 2002 10:00:15 -0700 (PDT) mail_from (clambert@sgi.com) Received: from mtv-vpn-hw-clambert-1.corp.sgi.com (onyx4@mtv-vpn-hw-clambert-1.corp.sgi.com [134.15.23.234]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA24737; Mon, 14 Oct 2002 10:00:04 -0700 (PDT) Date: Mon, 14 Oct 2002 10:00:04 -0700 (PDT) From: Christian Lambert X-X-Sender: clambert@onyx4.dhs.org To: linux-xfs@oss.sgi.com cc: Christian Lambert Subject: 2.4.19xfs + preempt causes hangs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clambert@sgi.com Precedence: bulk X-list: linux-xfs I've been running a stock debian 2.4.19 + xfs2.4.19 snapshot patch + preempt and this worked fine for like 3-4 days now. But this morning I came up and my system hung up when I did "ls" in the console. Then everything hung up from there and lead eventually to X hanging as well, the hard drive light was solid "on". I have a mix of reiserfs and xfs filesystems so I'm not sure what caused it, but I wanted to know if this is known to cause problems or it's supposed to work? I'm not using lock-break, just preempt. I think what might have trigged this hang is the updatedb (for locate) that ran during the night and maybe have hosed things up scanning thru the filesystems. -Christian From owner-linux-xfs@oss.sgi.com Mon Oct 14 10:07:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 10:07: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 g9EH7VtG005062 for ; Mon, 14 Oct 2002 10:07:31 -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 MAA86780; Mon, 14 Oct 2002 12:07: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 MAA52387; Mon, 14 Oct 2002 12:07:25 -0500 (CDT) Subject: Re: Log corruption? From: Eric Sandeen To: James Pearson Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: <3DAAF7D6.9B8EEADC@moving-picture.com> References: <3DAAF7D6.9B8EEADC@moving-picture.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 14 Oct 2002 12:04:19 -0500 Message-Id: <1034615059.2893.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 964 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-10-14 at 11:59, James Pearson wrote: > Thanks, that seems to compile OK. > > However, I have a couple of questions: > > When I was looking through the CVS history for xfs_log_recover.c, I > noticed this (similar) one line change was after a previous bigger > change to handle read-only mounts - does XFS 1.1 need something similar > as well? Most of that change was cosmetic... the bit I gave you was the part that might affect log corruption. Without that part, we might skip an important part of log recovery on filesystems which are mounted read-only. The rest of the log_recovery.c changes are mostly cleanups for benign things. > Also, when I boot the system from CD/floppy in rescue mode and attempt > to mount the root file system, I get the oops described below - but in > this case the mount is mounting read-write - so I'm a bit confused to as > why this read-only mount fix will help? The change I gave you will hopefully prevent the log from getting into the state (where it oopses on recovery) in the future. For a log -already- in that state, it won't help. You'll probably need to do an xfs_repair -L to get things going again. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Oct 14 10:09:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 10:09: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 g9EH9EtG005734 for ; Mon, 14 Oct 2002 10:09:14 -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 MAA30894; Mon, 14 Oct 2002 12:09: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 MAA55977; Mon, 14 Oct 2002 12:09:08 -0500 (CDT) Subject: Re: 2.4.19xfs + preempt causes hangs? From: Eric Sandeen To: Christian Lambert 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: 14 Oct 2002 12:06:02 -0500 Message-Id: <1034615162.2893.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 965 X-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 Christian - I don't have a lot of experience with pre-empt, but the best thing to do would be to break into KDB and see which process is hung, and what it's hung on... if you have kdb.... -Eric On Mon, 2002-10-14 at 12:00, Christian Lambert wrote: > > I've been running a stock debian 2.4.19 + xfs2.4.19 snapshot patch + preempt > and this worked fine for like 3-4 days now. But this morning I came up > and my system hung up when I did "ls" in the console. Then everything > hung up from there and lead eventually to X hanging as well, the hard drive > light was solid "on". I have a mix of reiserfs and xfs filesystems so I'm > not sure what caused it, but I wanted to know if this is known to cause > problems or it's supposed to work? I'm not using lock-break, just preempt. > I think what might have trigged this hang is the updatedb (for locate) that > ran during the night and maybe have hosed things up scanning thru the > filesystems. > > -Christian > > -- 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 14 10:19:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 10:19:07 -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 g9EHJ0tG007501 for ; Mon, 14 Oct 2002 10:19:00 -0700 Received: from rock.csd.sgi.com (rock.csd.sgi.com [130.62.75.10]) 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 KAA02604 for ; Mon, 14 Oct 2002 10:19:00 -0700 (PDT) mail_from (clambert@sgi.com) Received: from mtv-vpn-hw-clambert-1.corp.sgi.com (onyx4@mtv-vpn-hw-clambert-1.corp.sgi.com [134.15.23.234]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA25376; Mon, 14 Oct 2002 10:18:49 -0700 (PDT) Date: Mon, 14 Oct 2002 10:18:49 -0700 (PDT) From: Christian Lambert X-X-Sender: clambert@onyx4.dhs.org To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19xfs + preempt causes hangs? In-Reply-To: <1034615162.2893.12.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 966 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clambert@sgi.com Precedence: bulk X-list: linux-xfs I didn't apply the kdb patch because it had a problem patching main.c from the stock debian kernel (which is very close to kernel.org). patching file init/main.c Hunk #2 FAILED at 255. Hunk #3 succeeded at 448 (offset 18 lines). 1 out of 3 hunks FAILED -- saving rejects to file init/main.c.rej Maybe I should start from a CVS xfs full kernel tree, then apply the preempt patch on it so that I'd get kdb. -Christian On 14 Oct 2002, Eric Sandeen wrote: | Hi Christian - | | I don't have a lot of experience with pre-empt, but the best thing to do | would be to break into KDB and see which process is hung, and what it's | hung on... if you have kdb.... | | -Eric | | On Mon, 2002-10-14 at 12:00, Christian Lambert wrote: | > | > I've been running a stock debian 2.4.19 + xfs2.4.19 snapshot patch + preempt | > and this worked fine for like 3-4 days now. But this morning I came up | > and my system hung up when I did "ls" in the console. Then everything | > hung up from there and lead eventually to X hanging as well, the hard drive | > light was solid "on". I have a mix of reiserfs and xfs filesystems so I'm | > not sure what caused it, but I wanted to know if this is known to cause | > problems or it's supposed to work? I'm not using lock-break, just preempt. | > I think what might have trigged this hang is the updatedb (for locate) that | > ran during the night and maybe have hosed things up scanning thru the | > filesystems. | > | > -Christian | > | > | -- | 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 14 11:10:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 11: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 g9EIArtG016254 for ; Mon, 14 Oct 2002 11:10:53 -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 LAA02601 for ; Mon, 14 Oct 2002 11:10:52 -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 g9EI9mPZ000944 for ; Mon, 14 Oct 2002 20:09:48 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9EI9mF7000943 for linux-xfs@oss.sgi.com; Mon, 14 Oct 2002 20:09:48 +0200 Date: Mon, 14 Oct 2002 20:09:48 +0200 Message-Id: <200210141809.g9EI9mF7000943@lab343.munich.sgi.com> Subject: TAKE - switch to ilookup To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 967 X-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 Switch from iget_locked to ilookup in vn_get. We only want to get the inode if it actually is present in core. The new ilookup function allows us to do this easily instead of having to tear down the wrongly allocated inode again if it wasn't in memory. Date: Mon Oct 14 11:06:37 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:129883a linux/fs/xfs/linux/xfs_vnode.c - 1.103 - Switch to ilookup. From owner-linux-xfs@oss.sgi.com Mon Oct 14 11:52:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 11:52: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 g9EIqgtG023257 for ; Mon, 14 Oct 2002 11:52:42 -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 NAA30176 for ; Mon, 14 Oct 2002 13:52: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 NAA30521 for ; Mon, 14 Oct 2002 13:52:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9EIoFG32347; Mon, 14 Oct 2002 13:50:15 -0500 Message-Id: <200210141850.g9EIoFG32347@jen.americas.sgi.com> Date: Mon, 14 Oct 2002 13:50:15 -0500 Subject: TAKE - fast 8 byte swap implementation - backport from 2.5 To: linux-xfs@oss.sgi.com X-archive-position: 968 X-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 XFS benefits from this on ia32. Date: Mon Oct 14 11:52:05 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:129896a linux/include/asm-i386/byteorder.h - 1.3 - Better code for 8 byte swap implementation From owner-linux-xfs@oss.sgi.com Mon Oct 14 16:35:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 16:35:28 -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 g9ENZNtG007264 for ; Mon, 14 Oct 2002 16:35:24 -0700 Received: (qmail 1319 invoked from network); 14 Oct 2002 23:35:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 14 Oct 2002 23:35:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 0CF6B300B29; Tue, 15 Oct 2002 09:35:18 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B7F008AACB; Tue, 15 Oct 2002 09:35:18 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Christian Lambert Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19xfs + preempt causes hangs? In-reply-to: Your message of "Mon, 14 Oct 2002 10:18:49 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Oct 2002 09:35:13 +1000 Message-ID: <2926.1034638513@ocs3.intra.ocs.com.au> X-archive-position: 969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 14 Oct 2002 10:18:49 -0700 (PDT), Christian Lambert wrote: >I didn't apply the kdb patch because it had a problem patching main.c >from the stock debian kernel (which is very close to kernel.org). > >patching file init/main.c >Hunk #2 FAILED at 255. >Hunk #3 succeeded at 448 (offset 18 lines). >1 out of 3 hunks FAILED -- saving rejects to file init/main.c.rej That would be this patch against parse_options(). Hand edit init/main.c, find parse_options(), find init= and insert the kdb chunk (from #ifdef CONFIG_KDB down to #endif, minus the leading '+') immediately before that point. Index: 19.1/init/main.c --- 19.1/init/main.c Wed, 29 May 2002 14:00:22 +1000 kaos (linux-2.4/k/11_main.c 1.1.5.1.1.8.1.3.1.9.1.4 644) +++ 19.13/init/main.c Tue, 09 Apr 2002 11:23:13 +1000 kaos (linux-2.4/k/11_main.c 1.2.1.1.1.20 644) @@ -251,6 +255,34 @@ static void __init parse_options(char *l } if (next != NULL) *next++ = 0; +#ifdef CONFIG_KDB + /* kdb, kdb=on, kdb=off, kdb=early */ + if (strncmp(line, "kdb", 3) == 0) { + if (line[3] == '\0') { + /* Backward compatibility, kdb with no option means early activation */ + printk("Boot flag kdb with no options is obsolete, use kdb=early\n"); + kdb_on = 1; + kdb_flags |= KDB_FLAG_EARLYKDB; + continue; + } + if (line[3] == '=') { + if (strcmp(line+4, "on") == 0) { + kdb_on = 1; + continue; + } + if (strcmp(line+4, "off") == 0) { + kdb_on = 0; + continue; + } + if (strcmp(line+4, "early") == 0) { + kdb_on = 1; + kdb_flags |= KDB_FLAG_EARLYKDB; + continue; + } + printk("Boot flag %s not recognised, assumed to be environment variable\n", line); + } + } +#endif /* CONFIG_KDB */ if (!strncmp(line,"init=",5)) { line += 5; execute_command = line; From owner-linux-xfs@oss.sgi.com Mon Oct 14 21:47:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Oct 2002 21:47:27 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-229.uc.nombres.ttd.es [213.99.177.229]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F4kxtG018644 for ; Mon, 14 Oct 2002 21:47:01 -0700 Received: (qmail 29150 invoked by uid 1000); 15 Oct 2002 04:47:32 -0000 From: yoros@wanadoo.es Date: Tue, 15 Oct 2002 06:47:32 +0200 To: linux-xfs Subject: possible bug with xfsdump, -e and -l 1 Message-ID: <20021015044732.GA29110@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm new to this mailing list. The reason of this mail is one question about "xfsdump" with "-e" and "-l 1" switches. When I have yet a level 0 backup and I want to make a level 1 backup, xfsdump includes all files that have been recently created althought they have user.SGI_XFSDUMP_SKIP_FILE attribute set. I don't know the reason of this "bug?" but when I make the same level 1 backup again, it works fine. Ah, I set the attributes near in time of the execution of xfsdump, I think it could be the problem... Anybody can tell me anything of this malfunction ("bug")? Thank you for your time, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9q53kWIvihXTx06wRAhwRAJ9K7S4X507QWykenyQtvSonqQesfACgnC43 R3FZIiuAnrsXxg2cRv5R5oM= =znxZ -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-linux-xfs@oss.sgi.com Tue Oct 15 03:57:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 03:57:51 -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 g9FAvitG004559 for ; Tue, 15 Oct 2002 03:57:45 -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 181POL-00030w-00; Tue, 15 Oct 2002 11:57:37 +0100 Message-ID: <3DABF4A1.31498BFE@moving-picture.com> Date: Tue, 15 Oct 2002 11:57:37 +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: <3DAAF7D6.9B8EEADC@moving-picture.com> <1034615059.2893.10.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: 971 X-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 Thanks for the info - we'll give a go and see what happens ... James Eric Sandeen wrote: > > On Mon, 2002-10-14 at 11:59, James Pearson wrote: > > Thanks, that seems to compile OK. > > > > However, I have a couple of questions: > > > > When I was looking through the CVS history for xfs_log_recover.c, I > > noticed this (similar) one line change was after a previous bigger > > change to handle read-only mounts - does XFS 1.1 need something similar > > as well? > > Most of that change was cosmetic... the bit I gave you was the part that > might affect log corruption. Without that part, we might skip an > important part of log recovery on filesystems which are mounted > read-only. The rest of the log_recovery.c changes are mostly cleanups > for benign things. > > > Also, when I boot the system from CD/floppy in rescue mode and attempt > > to mount the root file system, I get the oops described below - but in > > this case the mount is mounting read-write - so I'm a bit confused to as > > why this read-only mount fix will help? > > The change I gave you will hopefully prevent the log from getting into > the state (where it oopses on recovery) in the future. For a log > -already- in that state, it won't help. You'll probably need to do an > xfs_repair -L to get things going again. > > -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 15 08:26:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 08:26:25 -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 g9FFQItG003507 for ; Tue, 15 Oct 2002 08:26:19 -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 g9FFQDo22049; Tue, 15 Oct 2002 17:26:13 +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 181Ta2-0000to-00; Tue, 15 Oct 2002 17:25:58 +0200 Date: Tue, 15 Oct 2002 17:25:58 +0200 From: Christian Guggenberger To: andrea@suse.de Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015172558.A3154@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: 12 X-archive-position: 972 X-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 Andrea, I'm trying to compile 2.4.20-pre10aa1 with xfs enabled as module. make modules_install ends up in: depmod: *** Unresolved symbols in /lib/modules/2.4.20-pre10aa1/kernel/fs/xfs/xfs.o depmod: do_generic_file_write what to do? Christian From owner-linux-xfs@oss.sgi.com Tue Oct 15 08:31:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 08:31:45 -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 g9FFVgtG004570 for ; Tue, 15 Oct 2002 08:31:43 -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 KAA20327 for ; Tue, 15 Oct 2002 10:31:37 -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 KAA48532 for ; Tue, 15 Oct 2002 10:31:37 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FFT8S05557; Tue, 15 Oct 2002 10:29:08 -0500 Message-Id: <200210151529.g9FFT8S05557@jen.americas.sgi.com> Date: Tue, 15 Oct 2002 10:29:08 -0500 Subject: TAKE - New space allocated to the AGFL is incorrectly marked busy To: linux-xfs@oss.sgi.com X-archive-position: 973 X-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 from Irix xfs_alloc_put_freelist marks the blocks it gets as "busy". However, this function is used in two different ways: 1. xfs_alloc_fix_freelist calls xfs_alloc_put_freelist to add new blocks to the freelist (that is, blocks it allocated with xfs_alloc_ag_vextent). 2. xfs_alloc_delrec calls xfs_alloc_put_freelist to free deleted b+tree blocks. In case 1, the blocks should not be on the busy list; in case 2, they should. Date: Tue Oct 15 08:17:33 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:129987a linux/fs/xfs/xfs_alloc.c - 1.157 - Remove xfs_alloc_mark_busy calls from xfs_alloc_put_freelist. Blocks were double-inserted by xfs_alloc_fix_freelist and xfs_alloc_delrec. Instead, only add to the freelist from xfs_alloc_delrec. linux/fs/xfs/xfs_alloc_btree.c - 1.72 - xfs_alloc_delrec adds freed space to the per-AG busy list after putting it on the AGFL. From owner-linux-xfs@oss.sgi.com Tue Oct 15 09:11:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 09:11:30 -0700 (PDT) Received: from imf03bis.bellsouth.net (mail203.mail.bellsouth.net [205.152.58.143]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FGBQtG008743 for ; Tue, 15 Oct 2002 09:11:26 -0700 Received: from Mother2 ([67.35.80.128]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021015161258.BFQR28929.imf03bis.bellsouth.net@Mother2>; Tue, 15 Oct 2002 12:12:58 -0400 Date: Tue, 15 Oct 2002 12:11:13 -0400 From: Greg Freemyer Subject: re[2]: Work Items To: Stephen Lord cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021015161258.BFQR28929.imf03bis.bellsouth.net@Mother2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9FGBRtG008747 X-archive-position: 974 X-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 >> 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. Assuming this is done before the 2.6.x kernels are released, what will the max. 2.6.x XFS-Linux filesystem be? Just Curious From owner-linux-xfs@oss.sgi.com Tue Oct 15 09:19:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 09:19:24 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FGJLtG009603 for ; Tue, 15 Oct 2002 09:19:22 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id SAA02305; Tue, 15 Oct 2002 18:27:54 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9FGJ94s014607; Tue, 15 Oct 2002 18:19:09 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9FGJ9pp006225; Tue, 15 Oct 2002 18:19:09 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9FGJ8rB006224; Tue, 15 Oct 2002 18:19:08 +0200 Date: Tue, 15 Oct 2002 18:19:08 +0200 From: Andrea Arcangeli To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015161908.GC2546@dualathlon.random> References: <20021015172558.A3154@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015172558.A3154@pc9391.uni-regensburg.de> User-Agent: Mutt/1.3.27i X-archive-position: 975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Tue, Oct 15, 2002 at 05:25:58PM +0200, Christian Guggenberger wrote: > Hi Andrea, > > I'm trying to compile 2.4.20-pre10aa1 with xfs enabled as module. > make modules_install ends up in: > > depmod: *** Unresolved symbols in > /lib/modules/2.4.20-pre10aa1/kernel/fs/xfs/xfs.o > depmod: do_generic_file_write > > what to do? I logged it so it will be fixed. You can link it into the kernel in the meantime (select Y instead of M). For some reason bleeding edge gcc from CVS generates a flood of symbol errors when I run depmod before rebooting, so I don't easily notice these missing exports anymore (I should run depmod post reboot to notice them). thanks, Andrea From owner-linux-xfs@oss.sgi.com Tue Oct 15 09:29:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 09:29:11 -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 g9FGT9tG010552 for ; Tue, 15 Oct 2002 09:29: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 LAA07417; Tue, 15 Oct 2002 11:27: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 LAA24069; Tue, 15 Oct 2002 11:27:47 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FGPIa07658; Tue, 15 Oct 2002 11:25:18 -0500 Subject: Re: re[2]: Work Items From: Steve Lord To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021015161258.BFQR28929.imf03bis.bellsouth.net@Mother2> References: <20021015161258.BFQR28929.imf03bis.bellsouth.net@Mother2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 11:25:17 -0500 Message-Id: <1034699117.1783.44.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 976 X-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-15 at 11:11, Greg Freemyer wrote: > >> 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. > > Assuming this is done before the 2.6.x kernels are released, what will the max. 2.6.x XFS-Linux filesystem be? > It becomes a function of pagesize and the size of the page->index field, metadata is cached in an address space, so the size of a filesystem is governed by the amount of space which can fit in one of these. So page index is a long, on ia32 we have 4K pages, I think this gets us to 16 Tbytes. 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 15 09:42:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 09:42: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 g9FGg2tG012057 for ; Tue, 15 Oct 2002 09:42:03 -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 g9FGg1o29024; Tue, 15 Oct 2002 18:42:01 +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 181UlQ-0001dQ-00; Tue, 15 Oct 2002 18:41:48 +0200 Date: Tue, 15 Oct 2002 18:41:48 +0200 From: Christian Guggenberger To: Andrea Arcangeli Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015184148.A5026@pc9391.uni-regensburg.de> References: <20021015172558.A3154@pc9391.uni-regensburg.de> <20021015161908.GC2546@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20021015161908.GC2546@dualathlon.random>; from andrea@suse.de on Tue, Oct 15, 2002 at 18:19:08 +0200 X-Mailer: Balsa 1.2.4 Lines: 26 X-archive-position: 977 X-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 15 Oct 2002 18:19:08 Andrea Arcangeli wrote: > On Tue, Oct 15, 2002 at 05:25:58PM +0200, Christian Guggenberger wrote: > > Hi Andrea, > > > > I'm trying to compile 2.4.20-pre10aa1 with xfs enabled as module. > > make modules_install ends up in: > > > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.20-pre10aa1/kernel/fs/xfs/xfs.o > > depmod: do_generic_file_write > > > > what to do? > > I logged it so it will be fixed. You can link it into the kernel in the > meantime (select Y instead of M). For some reason bleeding edge gcc from > CVS generates a flood of symbol errors when I run depmod before > rebooting, so I don't easily notice these missing exports anymore (I > should run depmod post reboot to notice them). thanks, nope, static linking ends up in an error, too. fs/fs.o: In function `xfs_write': fs/fs.o(.text+0xa1158): undefined reference to `do_generic_file_write' make: *** [vmlinux] Error 1 Christian From owner-linux-xfs@oss.sgi.com Tue Oct 15 09:55:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 09:55:53 -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 g9FGtntG014084 for ; Tue, 15 Oct 2002 09:55: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 LAA45616; Tue, 15 Oct 2002 11:55:37 -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 LAA27105; Tue, 15 Oct 2002 11:55:36 -0500 (CDT) Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems (was: root xfs filesystem executable bits bug comeback?) From: Eric Sandeen To: Ethan Benson , Axel Thimm Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021012204316.GP13549@plato.local.lan> 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> <20021012204316.GP13549@plato.local.lan> Content-Type: multipart/mixed; boundary="=-iv9Ac13yuJ6uVwqRFeUk" X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 15 Oct 2002 11:52:20 -0500 Message-Id: <1034700741.7978.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 978 X-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 --=-iv9Ac13yuJ6uVwqRFeUk Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, here's a patch that seems to take care of all the problems... I am not an acl-guru by -any- means though, so I'd appreciate any testing & sanity-checking. I'll ask the sgi acl-gurus to look at it as well. (I'm not very happy with the test -x fix, it seems like this should be much earlier - perhaps even the vfs could just take care of this for us...) -Eric On Sat, 2002-10-12 at 15:43, 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 (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). > > 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 set > > 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 permission > > flag set if you are root. > > s/te/the execute/ i presume. > > yes thats a separate bug. > > > 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). > > 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) > > > # ==========> 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 > > 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 + > > > # ==========> 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-- > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --=-iv9Ac13yuJ6uVwqRFeUk Content-Disposition: attachment; filename=xfs_acl.c.patch.gz Content-Type: application/x-gzip; name=xfs_acl.c.patch.gz Content-Transfer-Encoding: base64 H4sICOZHrD0AA3hmc19hY2wuYy5wYXRjaACVVW1v4kYQ/mx+xZwqpYBtsCGQ tyZNlDhqJJScAhddP1kbe0m2Advyrjm4a/57Z3YNGB+p2g8Ye3dmduaZ55l1 XRe6hcy7ap51J/PsRuQd3x+c9F2vOxNJsexOZXdpfiGLZp0o9Dv9vjUpODxE CvwB+P7poHfqe9DzvF7Dtm3Y71jz6XunvaHxubwEt993jsDWz8vLBvwikmhW xBx+Q//O60V1xYTPUimWFDlcMqVybdNwx5Oryd01iERZ5cGh5Gqexry5SPAZ Kmg7sN7Cj9ZZw/7fTg7Zal8ofRepiDfOUzFTPA91gLn2rx+51+2Fq5AnsWBJ c791NUEWRVzKZiFiiv5i/nZSXJ8c5TwuAxHQvaMTZwg2/RmorRqS4StnMc+t Nl8qWoVzwCdmsTlbWVa7fKdlSsuyeJ6nOYJZfj4zKaKM53OJ/t4ZdNuYUM5B vbIEpIqhSMQStMHv0O5i7zDQFJqfMGgL362cqyJPwA3u7p+uRib3vtd3jpEl 3qHjn+jk0RIj3yVROhfJC1xdj4AvhVTSAWwhYCe4BgIwHx5DmoBQEhZshlyk U/WZbyKJ4fwcQnQPJ39+DvDlOhiPWw3X+pkR2QZnRNSt7ocEX9XAAQrtwIEG h6j2r/HQcAsbWaN9t40PwBKn8I3DK1vwj3AUUoo0KQsvMrTg2DhVsBlQXibM A67m34TkDsR8xhWaJCsDGeG3MexSI6kdlYTgRy3//1LvO/CZ5Luui5zP04Up /SfMtRNZY/mQFuoUm/R0Hz4GowAdSA2W9rl9DILmthGaHoceUbs/6DmGHdtk V0lk9Cgy90KEcScW+tsB405E0kkjW2sSq3ig2lD62+8X+tZ1m1iRqbmr2yUU tktCkiK8PCoUe0YuPguippukz2m8cgElL0GtLTj5bKDXowMO4C74Gly34OAA PtWzx92m3oaLC+i3Wi3CbV1GoAHdxassdi2uUrPwruEbmskwPDksJ8OPHc23 o6re16d4G8nXFF9qEx+GvUTHjOUcB2eccsJFGTozZOKUFTNF6nUAowr1q0Re 6qSOvB5dDEf+cZkUBpzzeZStmpFGPovxD4kkxXeeTreTs9WqjqzqSF4wRHHB yv5He4S8EWa5aX+4WZdstegx6pCqvinLYzhlrjSn9JzCWUS7NKI61uS1nFMC K5/lOIFXpnxf34tHvc203o6tBZURqlXGaXg93dw96sG5V6BrlLZyuwlur76M JhWxukbx5nOtf9NnIl+lzg+PMZDUNV05o0rGaD8bddlYr9/Hug8Hjj/UhW/v wAbUu4ExyosabybMo9JN5K2+UezairOmbXunLqL8Qt+CuLVgVQohc/MVXaQs 27v8wjIk/v2X0WgjEuGYohxk+5zJN9z3iSN29VSzaJdNxZDuBcWNUCjY1q+3 Y43Y/cMk/PwYjIP7SfV61DrTiA2HmijHA7whNVGsCK88Ylr4MPkjeKQ5SiV1 SubD33ivI4MYDymNM739jMx7IyZYpSZPaaKs362dS/yvQiq8gZDVLI81eaUZ XlatOm8nNr6+04Nltn3WaPwD10n2MIEKAAA= --=-iv9Ac13yuJ6uVwqRFeUk-- From owner-linux-xfs@oss.sgi.com Tue Oct 15 10:16:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 10:16:33 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FHGQtG017380 for ; Tue, 15 Oct 2002 10:16:28 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id TAA03676; Tue, 15 Oct 2002 19:25:00 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9FHGG4s014716; Tue, 15 Oct 2002 19:16:16 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9FHGGpp012553; Tue, 15 Oct 2002 19:16:16 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9FHGFJ7012552; Tue, 15 Oct 2002 19:16:15 +0200 Date: Tue, 15 Oct 2002 19:16:15 +0200 From: Andrea Arcangeli To: Christian Guggenberger Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015171615.GF2546@dualathlon.random> References: <20021015172558.A3154@pc9391.uni-regensburg.de> <20021015161908.GC2546@dualathlon.random> <20021015184148.A5026@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015184148.A5026@pc9391.uni-regensburg.de> User-Agent: Mutt/1.3.27i X-archive-position: 979 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Tue, Oct 15, 2002 at 06:41:48PM +0200, Christian Guggenberger wrote: > On 15 Oct 2002 18:19:08 Andrea Arcangeli wrote: > >On Tue, Oct 15, 2002 at 05:25:58PM +0200, Christian Guggenberger wrote: > >> Hi Andrea, > >> > >> I'm trying to compile 2.4.20-pre10aa1 with xfs enabled as module. > >> make modules_install ends up in: > >> > >> depmod: *** Unresolved symbols in > >> /lib/modules/2.4.20-pre10aa1/kernel/fs/xfs/xfs.o > >> depmod: do_generic_file_write > >> > >> what to do? > > > >I logged it so it will be fixed. You can link it into the kernel in the > >meantime (select Y instead of M). For some reason bleeding edge gcc from > >CVS generates a flood of symbol errors when I run depmod before > >rebooting, so I don't easily notice these missing exports anymore (I > >should run depmod post reboot to notice them). thanks, > > nope, static linking ends up in an error, too. > > fs/fs.o: In function `xfs_write': > fs/fs.o(.text+0xa1158): undefined reference to `do_generic_file_write' > make: *** [vmlinux] Error 1 do_generic_file_write is missing, one patch is probably missing, I will fix it in a few days, the last usable xfs was probably in 2.4.20pre5aa1. Andrea From owner-linux-xfs@oss.sgi.com Tue Oct 15 10:57:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 10:57:31 -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 g9FHvRtG025677 for ; Tue, 15 Oct 2002 10:57:28 -0700 Received: from fwd03.sul.t-online.de by mailout05.sul.t-online.com with smtp id 181VwL-0000Bo-05; Tue, 15 Oct 2002 19:57:09 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.210.97]) by fmrl03.sul.t-online.com with esmtp id 181Vw5-1dqQ3kC; Tue, 15 Oct 2002 19:56:53 +0200 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9FHujuM014975; Tue, 15 Oct 2002 19:56:45 +0200 Date: Tue, 15 Oct 2002 19:56:44 +0200 From: Axel Thimm To: Eric Sandeen Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: [2.4.18-14SGI_XFS_1.2a1] acl problems Message-ID: <20021015175644.GA11169@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> <20021012153026.GA17332@bonzo.nirvana> <20021012204316.GP13549@plato.local.lan> <1034700741.7978.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1034700741.7978.7.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 980 X-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 Tue, Oct 15, 2002 at 11:52:20AM -0500, Eric Sandeen wrote: > Ok, here's a patch that seems to take care of all the problems... I am > not an acl-guru by -any- means though, so I'd appreciate any testing & > sanity-checking. I'll ask the sgi acl-gurus to look at it as well. The small testcase I scripted does well on it (1.2pre1 with your patch). Not only the permissions bit seem to be fine now, but also the ghost-acl entries are gone. > (I'm not very happy with the test -x fix, it seems like this should be > much earlier - perhaps even the vfs could just take care of this for > us...) Definitely makes me happy! ;) Thanks, Axel. -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Tue Oct 15 11:03:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 11:03:30 -0700 (PDT) Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FI3StG026699 for ; Tue, 15 Oct 2002 11:03:29 -0700 Received: from Mother2 ([67.35.80.128]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> for ; Tue, 15 Oct 2002 14:05:06 -0400 Date: Tue, 15 Oct 2002 14:03:21 -0400 From: Greg Freemyer Subject: Gaurenteed file write?? To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9FI3TtG026712 X-archive-position: 981 X-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 All, I have an iteration counter that I update every night. echo $ITERATION > /backup/iteration Recently this file was reset to 0. I suspect it was a case of the "zero filled file". For this specific file and shell script, what extra logic can I add that would give me the highest likelihood of a successful disk write. i.e. Would sync; sync; increase my odds of always successfully writing this file out? TIA Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Oct 15 11:12:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 11:12:19 -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 g9FICCtG028094 for ; Tue, 15 Oct 2002 11:12:14 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 181WAp-0000aT-00; Tue, 15 Oct 2002 19:12:07 +0100 Date: Tue, 15 Oct 2002 19:12:07 +0100 From: Christoph Hellwig To: Andrea Arcangeli Cc: Christian Guggenberger , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015191207.A2067@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrea Arcangeli , Christian Guggenberger , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20021015172558.A3154@pc9391.uni-regensburg.de> <20021015161908.GC2546@dualathlon.random> <20021015184148.A5026@pc9391.uni-regensburg.de> <20021015171615.GF2546@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021015171615.GF2546@dualathlon.random>; from andrea@suse.de on Tue, Oct 15, 2002 at 07:16:15PM +0200 X-archive-position: 982 X-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 Tue, Oct 15, 2002 at 07:16:15PM +0200, Andrea Arcangeli wrote: > On Tue, Oct 15, 2002 at 06:41:48PM +0200, Christian Guggenberger wrote: > > On 15 Oct 2002 18:19:08 Andrea Arcangeli wrote: > > >On Tue, Oct 15, 2002 at 05:25:58PM +0200, Christian Guggenberger wrote: > > >> Hi Andrea, > > >> > > >> I'm trying to compile 2.4.20-pre10aa1 with xfs enabled as module. > > >> make modules_install ends up in: > > >> > > >> depmod: *** Unresolved symbols in > > >> /lib/modules/2.4.20-pre10aa1/kernel/fs/xfs/xfs.o > > >> depmod: do_generic_file_write > > >> > > >> what to do? > > > > > >I logged it so it will be fixed. You can link it into the kernel in the > > >meantime (select Y instead of M). For some reason bleeding edge gcc from > > >CVS generates a flood of symbol errors when I run depmod before > > >rebooting, so I don't easily notice these missing exports anymore (I > > >should run depmod post reboot to notice them). thanks, > > > > nope, static linking ends up in an error, too. > > > > fs/fs.o: In function `xfs_write': > > fs/fs.o(.text+0xa1158): undefined reference to `do_generic_file_write' > > make: *** [vmlinux] Error 1 > > do_generic_file_write is missing, one patch is probably missing, I will > fix it in a few days, the last usable xfs was probably in 2.4.20pre5aa1. No. you removed that patch in your last release because marcelo merged a part of it.. Still required part of 00_o_direct-read-overflow-write-locking-xfs-1 below: diff -urNp 2.4.19rc1/include/linux/fs.h odirect/include/linux/fs.h --- 2.4.19rc1/include/linux/fs.h Tue Jun 25 23:56:21 2002 +++ odirect/include/linux/fs.h Wed Jun 26 17:42:48 2002 @@ -1434,6 +1434,7 @@ extern int generic_file_mmap(struct file extern int file_read_actor(read_descriptor_t * desc, struct page *page, unsigned long offset, unsigned long size); extern ssize_t generic_file_read(struct file *, char *, size_t, loff_t *); extern ssize_t generic_file_write(struct file *, const char *, size_t, loff_t *); +extern ssize_t do_generic_file_write(struct file *, const char *, size_t, loff_t *); extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_t *, read_actor_t); extern loff_t no_llseek(struct file *file, loff_t offset, int origin); extern loff_t generic_file_llseek(struct file *file, loff_t offset, int origin); diff -urNp 2.4.19rc1/mm/filemap.c odirect/mm/filemap.c --- 2.4.19rc1/mm/filemap.c Tue Jun 25 23:56:23 2002 +++ odirect/mm/filemap.c Wed Jun 26 17:42:50 2002 @@ -2914,7 +2917,7 @@ inline void remove_suid(struct inode *in * okir@monad.swb.de */ ssize_t -generic_file_write(struct file *file,const char *buf,size_t count, loff_t *ppos) +do_generic_file_write(struct file *file,const char *buf,size_t count, loff_t *ppos) { struct address_space *mapping = file->f_dentry->d_inode->i_mapping; struct inode *inode = mapping->host; @@ -2926,16 +2929,8 @@ generic_file_write(struct file *file,con int err; unsigned bytes; - if ((ssize_t) count < 0) - return -EINVAL; - - if (!access_ok(VERIFY_READ, buf, count)) - return -EFAULT; - cached_page = NULL; - down(&inode->i_sem); - pos = *ppos; err = -EINVAL; if (pos < 0) @@ -3114,7 +3109,6 @@ out_status: err = written ? written : status; out: - up(&inode->i_sem); return err; fail_write: status = -EFAULT; @@ -3141,7 +3135,6 @@ o_direct: mark_inode_dirty(inode); } *ppos = end; - invalidate_inode_pages2(mapping); } /* * Sync the fs metadata but not the minor inode changes and @@ -3152,6 +3145,30 @@ o_direct: goto out_status; } +EXPORT_SYMBOL(do_generic_file_write); + +ssize_t +generic_file_write(struct file *file,const char *buf,size_t count, loff_t *ppos) +{ + struct inode *inode = file->f_dentry->d_inode->i_mapping->host; + int err; + + if ((ssize_t) count < 0) + return -EINVAL; + + if (!access_ok(VERIFY_READ, buf, count)) + return -EFAULT; + + down(&inode->i_sem); + err = do_generic_file_write(file, buf, count, ppos); + + if ((err > 0) && (file->f_flags & O_DIRECT)) + invalidate_inode_pages2(file->f_dentry->d_inode->i_mapping); + up(&inode->i_sem); + + return err; +} + void __init page_cache_init(unsigned long mempages) { unsigned long htable_size, order; From owner-linux-xfs@oss.sgi.com Tue Oct 15 11:47:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 11: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 g9FIlntG032236 for ; Tue, 15 Oct 2002 11:47:50 -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 NAA38166; Tue, 15 Oct 2002 13:47:44 -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 NAA59913; Tue, 15 Oct 2002 13:47:43 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FIjDX11928; Tue, 15 Oct 2002 13:45:13 -0500 Subject: Re: Gaurenteed file write?? From: Steve Lord To: Greg Freemyer Cc: xfs mailing list In-Reply-To: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> References: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 13:45:13 -0500 Message-Id: <1034707513.1783.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 983 X-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-15 at 13:03, Greg Freemyer wrote: > All, > > I have an iteration counter that I update every night. > > echo $ITERATION > /backup/iteration > > Recently this file was reset to 0. > > I suspect it was a case of the "zero filled file". > > For this specific file and shell script, what extra logic can I add that would give me the highest likelihood of a successful disk write. > > i.e. Would sync; sync; increase my odds of always successfully writing this file out? > > TIA > Greg Freemyer > > Write a little program which opens a file and calls fsync on it. sync should do it too. 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 15 12:04:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 12:04:05 -0700 (PDT) Received: from hotmail.com (oe72.law3.hotmail.com [209.185.240.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FJ43tG001762 for ; Tue, 15 Oct 2002 12:04:03 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 Oct 2002 12:03:58 -0700 X-Originating-IP: [24.74.154.26] From: "Wendy Cheng" To: "Steve Lord" Cc: "xfs mailing list" References: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> <1034707513.1783.54.camel@jen.americas.sgi.com> Subject: Re: Gaurenteed file write?? Date: Tue, 15 Oct 2002 15:03:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 15 Oct 2002 19:03:58.0472 (UTC) FILETIME=[9DAA6880:01C2747D] X-archive-position: 984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_wendy_cheng@hotmail.com Precedence: bulk X-list: linux-xfs Along the same line, if I mount the file system synchronously (forget about performance for now), will any write gets gaurenteed to get flushed into the disk ? More specifically, if I do step 1: mount fs synchronously step 2: execute a program that does a fwrite() and ends. step 3: purposely power off the system. step 4: reboot. Could I see my file there after step 4 ? Thank you for the help. Wendy -------- ----- Original Message ----- From: "Steve Lord" To: "Greg Freemyer" Cc: "xfs mailing list" Sent: Tuesday, October 15, 2002 2:45 PM Subject: Re: Gaurenteed file write?? | On Tue, 2002-10-15 at 13:03, Greg Freemyer wrote: | > All, | > | > I have an iteration counter that I update every night. | > | > echo $ITERATION > /backup/iteration | > | > Recently this file was reset to 0. | > | > I suspect it was a case of the "zero filled file". | > | > For this specific file and shell script, what extra logic can I add that would give me the highest likelihood of a successful disk write. | > | > i.e. Would sync; sync; increase my odds of always successfully writing this file out? | > | > TIA | > Greg Freemyer | > | > | | Write a little program which opens a file and calls fsync on it. sync | should do it too. | | 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 15 12:07:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 12:07: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 g9FJ7CtG002528 for ; Tue, 15 Oct 2002 12:07: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 OAA18337; Tue, 15 Oct 2002 14:07:06 -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 OAA96542; Tue, 15 Oct 2002 14:07:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FJ4ak11971; Tue, 15 Oct 2002 14:04:36 -0500 Subject: Re: Gaurenteed file write?? From: Steve Lord To: Wendy Cheng Cc: xfs mailing list In-Reply-To: References: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> <1034707513.1783.54.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 14:04:35 -0500 Message-Id: <1034708676.1783.62.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 985 X-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-15 at 14:03, Wendy Cheng wrote: > Along the same line, if I mount the file system synchronously (forget about > performance for now), will any write gets gaurenteed to get flushed into the > disk ? More specifically, if I do > step 1: mount fs synchronously > step 2: execute a program that does a fwrite() and ends. > step 3: purposely power off the system. > step 4: reboot. > > Could I see my file there after step 4 ? Thank you for the help. Use wsync and sync mount options. That should do it. Probably sync on its own is enough. wsync makes xfs transactions synchronous, but the sync will make file writes synchronous and that flushes the log too. Steve > > Wendy > -------- > ----- Original Message ----- > From: "Steve Lord" > To: "Greg Freemyer" > Cc: "xfs mailing list" > Sent: Tuesday, October 15, 2002 2:45 PM > Subject: Re: Gaurenteed file write?? > > > | On Tue, 2002-10-15 at 13:03, Greg Freemyer wrote: > | > All, > | > > | > I have an iteration counter that I update every night. > | > > | > echo $ITERATION > /backup/iteration > | > > | > Recently this file was reset to 0. > | > > | > I suspect it was a case of the "zero filled file". > | > > | > For this specific file and shell script, what extra logic can I add that > would give me the highest likelihood of a successful disk write. > | > > | > i.e. Would sync; sync; increase my odds of always successfully writing > this file out? > | > > | > TIA > | > Greg Freemyer > | > > | > > | > | Write a little program which opens a file and calls fsync on it. sync > | should do it too. > | > | Steve > | > | -- > | > | Steve Lord voice: +1-651-683-3511 > | Principal Engineer, Filesystem Software email: lord@sgi.com > | -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Oct 15 14:02:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 14:02:11 -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 g9FL26tG017266 for ; Tue, 15 Oct 2002 14:02:07 -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 QAA30301 for ; Tue, 15 Oct 2002 16:02:01 -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 QAA18124 for ; Tue, 15 Oct 2002 16:02:01 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FKxT620090; Tue, 15 Oct 2002 15:59:29 -0500 Message-Id: <200210152059.g9FKxT620090@jen.americas.sgi.com> Date: Tue, 15 Oct 2002 15:59:29 -0500 Subject: TAKE - fix that extent code fix To: linux-xfs@oss.sgi.com X-archive-position: 986 X-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 Pilot error merging that change from Irix. The wrong xfs_alloc_mark_busy call was removed from the code. Date: Tue Oct 15 14:01:19 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:130045a linux/fs/xfs/xfs_alloc.c - 1.158 - fix previous change remove xfs_alloc_mark_busy from the free list code, not from the extent free code From owner-linux-xfs@oss.sgi.com Tue Oct 15 14:36:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 14:36:58 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FLaitG021059 for ; Tue, 15 Oct 2002 14:36:49 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id XAA07967; Tue, 15 Oct 2002 23:44:54 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9FLa84s015117; Tue, 15 Oct 2002 23:36:08 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9FLa8pp024024; Tue, 15 Oct 2002 23:36:08 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9FLa5EI024023; Tue, 15 Oct 2002 23:36:05 +0200 Date: Tue, 15 Oct 2002 23:36:05 +0200 From: Andrea Arcangeli To: Christoph Hellwig , Christian Guggenberger , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o Message-ID: <20021015213605.GG2546@dualathlon.random> References: <20021015172558.A3154@pc9391.uni-regensburg.de> <20021015161908.GC2546@dualathlon.random> <20021015184148.A5026@pc9391.uni-regensburg.de> <20021015171615.GF2546@dualathlon.random> <20021015191207.A2067@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015191207.A2067@infradead.org> User-Agent: Mutt/1.3.27i X-archive-position: 987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Tue, Oct 15, 2002 at 07:12:07PM +0100, Christoph Hellwig wrote: > No. you removed that patch in your last release because marcelo > merged a part of it.. correct, thanks. Andrea From owner-linux-xfs@oss.sgi.com Tue Oct 15 15:31:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 15:31: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 g9FMV7tG026589 for ; Tue, 15 Oct 2002 15:31:07 -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 RAA44922 for ; Tue, 15 Oct 2002 17:31:02 -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 RAA23728 for ; Tue, 15 Oct 2002 17:31:02 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FMSUK21724; Tue, 15 Oct 2002 17:28:30 -0500 Message-Id: <200210152228.g9FMSUK21724@jen.americas.sgi.com> Date: Tue, 15 Oct 2002 17:28:30 -0500 Subject: TAKE - yet more allocation fixes To: linux-xfs@oss.sgi.com X-archive-position: 988 X-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 I want to restart the day and do it over - its been such fun! This is yet another fix to that fix, this time dealing with little vs big endian issues in the code. Merged some code without taking account of endian issues, the agf_seqno field we use in the new code is disk byte ordered, need to flip it. Date: Tue Oct 15 15:29:45 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:130055a linux/fs/xfs/xfs_alloc_btree.c - 1.73 - endian convert agf_seqno before passing it into the mark_busy code. From owner-linux-xfs@oss.sgi.com Tue Oct 15 15:36:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 15:36:54 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FMantG027572 for ; Tue, 15 Oct 2002 15:36:50 -0700 Received: (qmail 5027 invoked by uid 500); 15 Oct 2002 22:36:26 -0000 Subject: Request for known XFS bugs. From: Austin Gonyou To: linux-xfs@oss.sgi.com Cc: andrea@suse.de Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/trnrIQXZmbA44KWb0PS" Organization: Coremetrics, Inc. Message-Id: <1034721379.4972.28.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 15 Oct 2002 17:36:26 -0500 X-archive-position: 989 X-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 --=-/trnrIQXZmbA44KWb0PS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm having a severe problem with a configuration, but I'm not sure where this problem lies. Thus, I would like to request from the XFS team, any known issues regarding kernel 2.4.19, xfs, and 2.4.19-rc5-aa1 patch on quad P4 Xeon boxen.=20 I don't know if the issue is XFS, but I don't know it's *not* either. The server stats right now, are that I have two Dell 6650's with 8GB ram, RH 7.2 from the xfs 1.1 installer base, with most recent redhat updates, QLogic 2300Fs atached to ~1TB - 3TB of FC2 storage using LVM for volume management.=20 The symptoms are that after about 6 days of uptime with loadavg ~10-12% most of the time, running oracle8i and some other apps we have, the box locks.=20 Usually bad enough that none of the volumes ever get's shut down in any way, and usually corrupting the xfs log header, so that I have to run "xfs_repair -L /dev/vg/somevol" to let the volume mount. I keep hitting the pagebuf.c mount bug which was fixed some time ago, where mount on an unrepaired file system causes a kernel BUG() at page_buf.c:32(or something simliar, I can send a ksymoops output if anyone can help). I'm only curious if there is something in XFS or in the 2.4.19-rc5-aa1 kernel patch that could cause this behaviour, and of course what that might be.=20 This is very urgent, so if anyone can mail me directly to help resolve this, I'm more than happy to take the time to talk and try suggestions.=20 TIA.=20 p.s. We've performed all the usual diagnostics, troubleshooting, etc with all vendors in this situation, but still cannot find a resolution because when the box crashes, there are no bad log entries, or noticeable bad messages anywhere.=20 --=20 Austin Gonyou Coremetrics, Inc. --=-/trnrIQXZmbA44KWb0PS 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 iD8DBQA9rJhj94g6ZVmFMoIRAgiOAJ9o45X3TySSvtoqbZm++NWuivrI6ACfSNyr DpW4yGS92EgPgtPvoNqLkNA= =MrGN -----END PGP SIGNATURE----- --=-/trnrIQXZmbA44KWb0PS-- From owner-linux-xfs@oss.sgi.com Tue Oct 15 16:30:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 16:30: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 g9FNUKtG000740 for ; Tue, 15 Oct 2002 16:30:21 -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 SAA57133 for ; Tue, 15 Oct 2002 18:30:15 -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 SAA98141 for ; Tue, 15 Oct 2002 18:30:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9FNRg523030; Tue, 15 Oct 2002 18:27:42 -0500 Message-Id: <200210152327.g9FNRg523030@jen.americas.sgi.com> Date: Tue, 15 Oct 2002 18:27:42 -0500 Subject: TAKE - To: linux-xfs@oss.sgi.com X-archive-position: 990 X-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 more endian screwups in this code, this is the last one or I quit! Date: Tue Oct 15 16:29:53 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:130067a linux/fs/xfs/xfs_alloc.c - 1.159 - put back the endian flip we lost about 3 revisions back From owner-linux-xfs@oss.sgi.com Tue Oct 15 21:41:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Oct 2002 21:41:42 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G4fctG024812 for ; Tue, 15 Oct 2002 21:41:39 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9G4fWf30168 for ; Wed, 16 Oct 2002 00:41:32 -0400 Message-ID: <3DACEDFD.B96BB72C@splentec.com> Date: Wed, 16 Oct 2002 00:41:33 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: hitting the BUG() in filemap.c:843 (in unlock_page()) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Hello, We have this scenario: xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD. When md is set up with 3 (odd #) devices, then a mount sleeps indefinitely on down(), and when md is set up with 4 devices, then the kernel oopses at filemap.c:843 in unlock_page() the BUG() statement. The stack (of an SMP system) just prior to the oops is attached below. Now I've only been looking briefly at the code but have already noticed that _end_pagebuf_page_io_multi() does a unlock_page(), I'd guess for a good reason. It nevertheless breaks when set up with the above scenario. My guess would be that there's a wrong assumption somewhere. ((The same scenario, but with ext2 fs, doesn't oops.)) Can you please provide any hints? TIA, -- Luben >>EIP; c0135e65 <===== Trace; c027c2ea <_end_pagebuf_page_io_multi+da/100> Trace; c027c32f <_end_io_multi_full+1f/30> Trace; c0317cb0 Trace; c0318470 Trace; c031dde2 Trace; c02b01d1 Trace; f88abc08 <[3w-xxxx]tw_post_command_packet+38/120> Trace; c027c310 <_end_io_multi_full+0/30> Trace; c027c59c <_pagebuf_page_io+22c/500> Trace; c027c95a <_page_buf_page_apply+ea/1a0> Trace; c027cf18 <_pagebuf_segment_apply+f8/120> Trace; c027ca92 Trace; c027b3b6 <_pagebuf_lookup_pages+2b6/330> Trace; c027c0a8 Trace; c027b8d2 Trace; c026e570 Trace; c0252aa4 Trace; c027bddf Trace; c025be3a Trace; c02a4469 Trace; c02a9fe0 Trace; c0218bb0 Trace; c02187f0 Trace; c0216c8e Trace; c025e05c Trace; c0267f06 Trace; c0267209 Trace; c02708c7 Trace; c02709ef Trace; c02876e2 Trace; c014ccfa Trace; c014d6d2 Trace; c014cc4b Trace; c014da74 Trace; c01628f3 Trace; c0162c30 Trace; c0162a79 Trace; c016313f Trace; c01094ab From owner-linux-xfs@oss.sgi.com Wed Oct 16 00:42:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 00:42:53 -0700 (PDT) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G7gktG003719 for ; Wed, 16 Oct 2002 00:42:47 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g9G7h3v18171; Wed, 16 Oct 2002 09:43:03 +0200 Date: Wed, 16 Oct 2002 09:43:03 +0200 (CEST) From: Matteo Centonza To: Luben Tuikov cc: linux-xfs Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page()) In-Reply-To: <3DACEDFD.B96BB72C@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi, > We have this scenario: > > xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD. > our setup here differs only in having an IDE subsystem. In our case xfs has internal log. > When md is set up with 3 (odd #) devices, then > a mount sleeps indefinitely on down(), and when > md is set up with 4 devices, then the kernel > oopses at filemap.c:843 in unlock_page() the BUG() > statement. > > The stack (of an SMP system) just prior to the > oops is attached below. > Our has 4 disks and hits the same kernel BUG with 2.4.19 (CVS as of 20020806). Although i've lost the oops trace, i remember it was very similar to this. > Now I've only been looking briefly at the code > but have already noticed that _end_pagebuf_page_io_multi() > does a unlock_page(), I'd guess for a good reason. > It nevertheless breaks when set up with the above scenario. > My guess would be that there's a wrong assumption somewhere. > > ((The same scenario, but with ext2 fs, doesn't oops.)) We are currently stick to 2.4.18 (Release 1.1) and it works very well. Thanks, -m From owner-linux-xfs@oss.sgi.com Wed Oct 16 01:06:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 01:06:39 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G86XtG005694 for ; Wed, 16 Oct 2002 01:06:34 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id DAA11127 for ; Wed, 16 Oct 2002 03:26:22 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9G1Fs4s015664 for ; Wed, 16 Oct 2002 03:15:55 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9G1Fqpp001787 for ; Wed, 16 Oct 2002 03:15:52 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9G1FVL6001777; Wed, 16 Oct 2002 03:15:31 +0200 Date: Wed, 16 Oct 2002 03:15:31 +0200 From: Andrea Arcangeli To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Request for known XFS bugs. Message-ID: <20021016011531.GH2546@dualathlon.random> References: <1034721379.4972.28.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1034721379.4972.28.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.3.27i X-archive-position: 993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Tue, Oct 15, 2002 at 05:36:26PM -0500, Austin Gonyou wrote: > I'm having a severe problem with a configuration, but I'm not sure where > this problem lies. Thus, I would like to request from the XFS team, any > known issues regarding kernel 2.4.19, xfs, and 2.4.19-rc5-aa1 patch on > quad P4 Xeon boxen. > > I don't know if the issue is XFS, but I don't know it's *not* either. > The server stats right now, are that I have two Dell 6650's with 8GB > ram, RH 7.2 from the xfs 1.1 installer base, with most recent redhat > updates, QLogic 2300Fs atached to ~1TB - 3TB of FC2 storage using LVM > for volume management. > > The symptoms are that after about 6 days of uptime with loadavg ~10-12% > most of the time, running oracle8i and some other apps we have, the box > locks. > > Usually bad enough that none of the volumes ever get's shut down in any > way, and usually corrupting the xfs log header, so that I have to run > "xfs_repair -L /dev/vg/somevol" to let the volume mount. I keep hitting > the pagebuf.c mount bug which was fixed some time ago, where mount on an > unrepaired file system causes a kernel BUG() at page_buf.c:32(or > something simliar, I can send a ksymoops output if anyone can help). > > I'm only curious if there is something in XFS or in the 2.4.19-rc5-aa1 > kernel patch that could cause this behaviour, and of course what that > might be. > > This is very urgent, so if anyone can mail me directly to help resolve > this, I'm more than happy to take the time to talk and try suggestions. I would try again with 2.4.20pre10aa1 + the patch posted by Christoph in the previous email about xfs that should allow compilation of xfs. You also may want to try to regenerate the fs with mkfs instead of using fsck just in case. I would like to know if it helps or not. Thanks. Andrea From owner-linux-xfs@oss.sgi.com Wed Oct 16 01:12:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 01:12:22 -0700 (PDT) Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G8CHtG006450 for ; Wed, 16 Oct 2002 01:12:18 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla1.xs4all.nl (8.12.3/8.12.3) with ESMTP id g9G8CEnm034166; Wed, 16 Oct 2002 10:12:15 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g9G8CEm89635; Wed, 16 Oct 2002 10:12:14 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 16 Oct 2002 10:12:14 +0200 (CEST) From: Seth Mos To: Austin Gonyou cc: linux-xfs@oss.sgi.com, Subject: Re: Request for known XFS bugs. In-Reply-To: <1034721379.4972.28.camel@UberGeek.coremetrics.com> Message-ID: <20021016100602.V88870-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 994 X-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 15 Oct 2002, Austin Gonyou wrote: > I don't know if the issue is XFS, but I don't know it's *not* either. > The server stats right now, are that I have two Dell 6650's with 8GB > ram, RH 7.2 from the xfs 1.1 installer base, with most recent redhat > updates, QLogic 2300Fs atached to ~1TB - 3TB of FC2 storage using LVM > for volume management. Does the box use interrupt sharing? There are also a lot of people on linux-poweredge@dell.com that see interrupt only handled by the first processor. > The symptoms are that after about 6 days of uptime with loadavg ~10-12% > most of the time, running oracle8i and some other apps we have, the box > locks. I could get this on a pe2550 that shared interrupts with a gigabit nic. If you loaded NFS enough it would lock up. These dell boxen are quite sensitive to the issue. Perhaps because of the serverworks chipsets. > Usually bad enough that none of the volumes ever get's shut down in any > way, and usually corrupting the xfs log header, so that I have to run Sounds familiar enough. > p.s. We've performed all the usual diagnostics, troubleshooting, etc > with all vendors in this situation, but still cannot find a resolution > because when the box crashes, there are no bad log entries, or > noticeable bad messages anywhere. Did you do the interrupt trick? Switch of what you don't need in the bios and reboot. Go into the bios and switch on the scroll,caps and num lock. Press Ctrl-E and system should beep at you. reboot. It will nog have reassigned the IRQ table. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Oct 16 01:46:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 01:46:50 -0700 (PDT) Received: from intranet.mtp.eprocess.fr (imap.eprocess.fr [62.23.135.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G8khtG008872 for ; Wed, 16 Oct 2002 01:46:44 -0700 Received: from eprocess.fr (fcombernous.mtp.eprocess.fr [192.168.2.14]) by intranet.mtp.eprocess.fr (8.9.3/8.9.3) with ESMTP id KAA09912 for ; Wed, 16 Oct 2002 10:46:37 +0200 Message-ID: <3DAD2783.1070506@eprocess.fr> Date: Wed, 16 Oct 2002 10:46:59 +0200 From: Fabien Combernous User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: to compare journalised file systems Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by intranet.mtp.eprocess.fr id KAA09912 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9G8kjtG008876 X-archive-position: 995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fcombernous@eprocess.fr Precedence: bulk X-list: linux-xfs Lo, Actualy i'm looking for documents about journalised file system, in order to be able to compare them self. I need accurate information if i want to make a good study. Thoses informations have to permit me to get answer about table like this : Features \ fs | xfs | ext3 | jfs | reiserfs | ------------------------------------------------- chattr | ? | Y | ? | ? | ------------------------------------------------- quotas | Y | ? | Y | ? | ------------------------------------------------- removable fs | ? | ? | N | ? | ------------------------------------------------- NFS | Y | Y | ? | ? | ------------------------------------------------- samba | ? | ? | ? | ? | ------------------------------------------------- coda | ? | ? | ? | ? | ------------------------------------------------- ... My line is to remove all '?' by 'Y' or 'N' for all my table. I know thoses links talking about xfs : http://oss.sgi.com/projects/xfs/ http://bulmalug.net/body.phtml?nIdNoticia=1154 but a need more informations. I know bonnie++ as disk tool tester, but i would like to have several points of view with several tools. If you know some others links or books or good tools, you are wellcom. Thanks Fabien. -- Fabien COMBERNOUS - IT Engineer eProcess - Parc Club du Mill閚aire Batiment n 6 1025 rue Henri Becquerel - 34000 Montpellier FRANCE http://www.eprocess.fr - +33 (0)4 67 13 84 50 From owner-linux-xfs@oss.sgi.com Wed Oct 16 01:55:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 01:55:47 -0700 (PDT) Received: from atlas.cc.itu.edu.tr ([160.75.2.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G8tatG009716 for ; Wed, 16 Oct 2002 01:55:39 -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 g9G8qEB17060 for ; Wed, 16 Oct 2002 11:52:15 +0300 Date: Wed, 16 Oct 2002 11:54:30 +0300 From: 辝ref Tufan 辝n To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2Pre and nfs problem Message-Id: <20021016115430.724d3b18.tufan@itu.edu.tr> In-Reply-To: <20021012140349.3c28bcc9.tufan@itu.edu.tr> References: <20021011124432.253ca55a.tufan@itu.edu.tr> <1034352726.1162.7.camel@rose.americas.sgi.com> <20021012140349.3c28bcc9.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 g9G8qEB17060 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9G8tftG009752 X-archive-position: 996 X-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 Hi,,, I still have problems with nfs. I decided to run xfs_repair on my filesystems. On one of my fs xfs_repairs ends with the following error. I'm using XFS 1.2pre kernel and utilities.. The second xfs_repair ( for my second fs) is running now. If i get something wrong , I will let you know. Does anybody have any idea what can I do.. [root@lnxsrv2 /root]# tail /eski_disk/lnxsrv2.log disconnected dir inode 421774644, moving to lost+found disconnected dir inode 421774648, moving to lost+found disconnected dir inode 421780236, moving to lost+found disconnected dir inode 421789725, moving to lost+found disconnected dir inode 421793356, moving to lost+found disconnected dir inode 421793357, moving to lost+found disconnected dir inode 421820974, moving to lost+found Phase 7 - verify and correct link counts... fatal error -- couldn't map inode 68355923, err = 990 On Sat, 12 Oct 2002 14:03:49 +0300 辝ref Tufan 辝n wrote: > > 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 > > -- 辝ref Tufan 辝n 軹-B軩B Sistem Destek Grubu From owner-linux-xfs@oss.sgi.com Wed Oct 16 01:56:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 01:56:33 -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 g9G8uTtG010117 for ; Wed, 16 Oct 2002 01:56:29 -0700 Received: from erbenson.alaska.net (135-pm15.nwc.alaska.net [209.112.141.135]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9G8uShH075496 for ; Wed, 16 Oct 2002 00:56:28 -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 B5E583A0C for ; Wed, 16 Oct 2002 00:56:26 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 000964104E2; Wed, 16 Oct 2002 00:56:26 -0800 (AKDT) Date: Wed, 16 Oct 2002 00:56:26 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016085626.GB27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3DAD2783.1070506@eprocess.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <3DAD2783.1070506@eprocess.fr> 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: 997 X-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 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 10:46:59AM +0200, Fabien Combernous wrote: > Lo, >=20 > Actualy i'm looking for documents about journalised file system, in=20 > order to be able to compare them self. I need accurate information if i= =20 > want to make a good study. >=20 > Thoses informations have to permit me to get answer about table like this= : >=20 > Features \ fs | xfs | ext3 | jfs | reiserfs | > ------------------------------------------------- > chattr | ? | Y | ? | ? | if you mean immutable/append only xfs doesn't have that, but its been found it would be easy to add. reiserfs already did add it. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --GRPZ8SYKNexpdSJ7 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 iEYEARECAAYFAj2tKboACgkQJKx7GixEevxNuwCgj/HZNG46S0NVsf0vU0lNJFzA 5JwAoICtsv5OVf+gqb+1SOk2vLTde8LV =OR81 -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 02:20:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 02:20:14 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G9K7tG011604 for ; Wed, 16 Oct 2002 02:20:08 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g9G9K4f02716 for linux-xfs@oss.sgi.com.KAV; Wed, 16 Oct 2002 11:20:04 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g9G9K1b02612; Wed, 16 Oct 2002 11:20:02 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g9G9Mj903217; Wed, 16 Oct 2002 11:22:45 +0200 Subject: Re: to compare journalised file systems From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Fabien Combernous Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DAD2783.1070506@eprocess.fr> References: <3DAD2783.1070506@eprocess.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 16 Oct 2002 11:22:45 +0200 Message-Id: <1034760165.3017.5.camel@venus> Mime-Version: 1.0 X-archive-position: 998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs On Wed, 2002-10-16 at 10:46, Fabien Combernous wrote: > Lo, > > Actualy i'm looking for documents about journalised file system, in > order to be able to compare them self. I need accurate information if i > want to make a good study. > > Thoses informations have to permit me to get answer about table like this : > > Features \ fs | xfs | ext3 | jfs | reiserfs | > ------------------------------------------------- > chattr | ? | Y | ? | ? | > ------------------------------------------------- > quotas | Y | ? | Y | ? | > ------------------------------------------------- > removable fs | ? | ? | N | ? | > ------------------------------------------------- > NFS | Y | Y | ? | ? | > ------------------------------------------------- > samba | ? | ? | ? | ? | > ------------------------------------------------- Is samba dependent on filesystem? I have been using XFS and samba for about 1.5-2 years with no problems. Regards, Olaf From owner-linux-xfs@oss.sgi.com Wed Oct 16 02:25:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 02:25:59 -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 g9G9PutG012248 for ; Wed, 16 Oct 2002 02:25:57 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9E6D2AC4A; Wed, 16 Oct 2002 11:21:23 +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 4D8BD1900B; Wed, 16 Oct 2002 11:21:22 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 8220230881D; Wed, 16 Oct 2002 11:25:54 +0200 (CEST) Message-ID: <3DAD30A2.23B77AE8@ch.sauter-bc.com> Date: Wed, 16 Oct 2002 11:25:54 +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: Olaf =?iso-8859-1?Q?Fr=B1czyk?= Cc: Fabien Combernous , linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems References: <3DAD2783.1070506@eprocess.fr> <1034760165.3017.5.camel@venus> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 999 X-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 Olaf Fr眂zyk schrieb: > > On Wed, 2002-10-16 at 10:46, Fabien Combernous wrote: > > Lo, > > > > Actualy i'm looking for documents about journalised file system, in > > order to be able to compare them self. I need accurate information if i > > want to make a good study. > > > > Thoses informations have to permit me to get answer about table like this : > > > > Features \ fs | xfs | ext3 | jfs | reiserfs | > > ------------------------------------------------- > > chattr | ? | Y | ? | ? | > > ------------------------------------------------- > > quotas | Y | ? | Y | ? | > > ------------------------------------------------- > > removable fs | ? | ? | N | ? | > > ------------------------------------------------- > > NFS | Y | Y | ? | ? | > > ------------------------------------------------- > > samba | ? | ? | ? | ? | > > ------------------------------------------------- > Is samba dependent on filesystem? > I have been using XFS and samba for about 1.5-2 years with no problems. Since Samba is userspace, the fs shouldn't matter. On the other side Samba can make use of fs features like ACLs so the fs isn't totally irrelevant. Simon > > Regards, > > Olaf From owner-linux-xfs@oss.sgi.com Wed Oct 16 02:47:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 02:47:25 -0700 (PDT) Received: from skreak.org (W00t@ddsl-66-161-218-122.fuse.net [66.161.218.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G9lNtG013635 for ; Wed, 16 Oct 2002 02:47:23 -0700 Received: (qmail 1286 invoked from network); 16 Oct 2002 09:50:47 -0000 Received: from localhost (127.0.0.1) by skreak.org with SMTP; 16 Oct 2002 09:50:47 -0000 Date: Wed, 16 Oct 2002 05:50:47 -0400 (EDT) From: TJ Easter To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems In-Reply-To: <20021016085626.GB27982@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1000 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tje@skreak.org Precedence: bulk X-list: linux-xfs Anyone know if there are plans to impliment the immutable/append-only options? Regards, -tje- On Wed, 16 Oct 2002, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 10:46:59AM +0200, Fabien Combernous wrote: > > Lo, > > > > Actualy i'm looking for documents about journalised file system, in > > order to be able to compare them self. I need accurate information if i > > want to make a good study. > > > > Thoses informations have to permit me to get answer about table like this : > > > > Features \ fs | xfs | ext3 | jfs | reiserfs | > > ------------------------------------------------- > > chattr | ? | Y | ? | ? | > > if you mean immutable/append only xfs doesn't have that, but its been > found it would be easy to add. reiserfs already did add it. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > From owner-linux-xfs@oss.sgi.com Wed Oct 16 02:47:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 02:47:35 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G9lUtG013694 for ; Wed, 16 Oct 2002 02:47:32 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g9G9lSa17071 for linux-xfs@oss.sgi.com.KAV; Wed, 16 Oct 2002 11:47:28 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g9G9lP317036; Wed, 16 Oct 2002 11:47:25 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g9G9o8903395; Wed, 16 Oct 2002 11:50:08 +0200 Subject: Re: to compare journalised file systems From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Simon Matter Cc: Fabien Combernous , linux-xfs@oss.sgi.com In-Reply-To: <3DAD30A2.23B77AE8@ch.sauter-bc.com> References: <3DAD2783.1070506@eprocess.fr> <1034760165.3017.5.camel@venus> <3DAD30A2.23B77AE8@ch.sauter-bc.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 16 Oct 2002 11:50:08 +0200 Message-Id: <1034761808.3016.17.camel@venus> Mime-Version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by goliath.sylaba.poznan.pl id g9G9lP317036 X-MIME-Autoconverted: from 8bit to quoted-printable by goliath.sylaba.poznan.pl id g9G9lSa17071 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9G9lXtG013729 X-archive-position: 1001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs On Wed, 2002-10-16 at 11:25, Simon Matter wrote: > Olaf Fr眂zyk schrieb: > > > > On Wed, 2002-10-16 at 10:46, Fabien Combernous wrote: > > > Lo, > > > > > > Actualy i'm looking for documents about journalised file system, in > > > order to be able to compare them self. I need accurate information if i > > > want to make a good study. > > > > > > Thoses informations have to permit me to get answer about table like this : > > > > > > Features \ fs | xfs | ext3 | jfs | reiserfs | > > > ------------------------------------------------- > > > chattr | ? | Y | ? | ? | > > > ------------------------------------------------- > > > quotas | Y | ? | Y | ? | > > > ------------------------------------------------- > > > removable fs | ? | ? | N | ? | > > > ------------------------------------------------- > > > NFS | Y | Y | ? | ? | > > > ------------------------------------------------- > > > samba | ? | ? | ? | ? | > > > ------------------------------------------------- > > Is samba dependent on filesystem? > > I have been using XFS and samba for about 1.5-2 years with no problems. > > Since Samba is userspace, the fs shouldn't matter. On the other side > Samba can make use of fs features like ACLs so the fs isn't totally > irrelevant. Yes. Since 2.2.5 (or.4) DACLs work with samba.(There is a small problem: DACL rwx gives you for samba for created files and directories rwx, but on unix side using 'touch' gives rwx for directories and rw- for files). There is also an idea to move DOS attributes :System,Hidden,Read-Only, Archived to EAs in XFS. This should give you much cleaner permissions, as they are now mapped into normal user/group/other permissions. Regards, Olaf From owner-linux-xfs@oss.sgi.com Wed Oct 16 04:16:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 04:17:01 -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 g9GBGrtG025419 for ; Wed, 16 Oct 2002 04:16:54 -0700 Received: (qmail 1836 invoked from network); 16 Oct 2002 11:16:51 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Oct 2002 11:16:51 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 07338300B3D; Wed, 16 Oct 2002 21:16:49 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id CEF9A108F for ; Wed, 16 Oct 2002 21:16:49 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: 2.4.20-pre10-aa1: unresolved symbol in xfs.o In-reply-to: Your message of "Tue, 15 Oct 2002 18:19:08 +0200." <20021015161908.GC2546@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 2002 21:16:44 +1000 Message-ID: <30757.1034767004@ocs3.intra.ocs.com.au> X-archive-position: 1002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 15 Oct 2002 18:19:08 +0200, Andrea Arcangeli wrote: >For some reason bleeding edge gcc from >CVS generates a flood of symbol errors when I run depmod before >rebooting, so I don't easily notice these missing exports anymore (I >should run depmod post reboot to notice them). thanks, modutils 2.4.17 has a change for recent binutils. From owner-linux-xfs@oss.sgi.com Wed Oct 16 04:21:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 04:22:01 -0700 (PDT) Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GBLutG026287 for ; Wed, 16 Oct 2002 04:21:57 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA02916; Wed, 16 Oct 2002 13:21:39 +0200 (MET DST) Date: Wed, 16 Oct 2002 13:21:39 +0200 (MEST) From: Geert Uytterhoeven To: Linux Kernel Development cc: linux-xfs@oss.sgi.com Subject: XFS build error on m68k in 2.5.43 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-xfs When compiling a kernel for m68k (with CONFIG_XFS_FS=m), I get this error: | make -f fs/xfs/Makefile | rm -f fs/xfs/built-in.o; m68k-linux-ar rcs fs/xfs/built-in.o | m68k-linux-gcc -Wp,-MD,fs/xfs/linux/.xfs_stats.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -fno-strength-reduce -ffixed-a2 -nostdinc -iwithprefix include -DMODULE -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_stats -c -o fs/xfs/linux/xfs_stats.o fs/xfs/linux/xfs_stats.c | In file included from fs/xfs/xfs.h:70, | from fs/xfs/linux/xfs_stats.c:33: | fs/xfs/xfs_bmap_btree.h:662: badly punctuated parameter list in `#define' | fs/xfs/xfs_log.h:62: warning: `_lsn_cmp' defined but not used | make[2]: *** [fs/xfs/linux/xfs_stats.o] Error 1 | make[1]: *** [fs/xfs] Error 2 | make: *** [fs] Error 2 Since it's not obvious to me what's wrong with that define, I'm asking here. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-xfs@oss.sgi.com Wed Oct 16 04:30:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 04:30:45 -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 g9GBUbtG027518 for ; Wed, 16 Oct 2002 04:30:38 -0700 Received: (qmail 2013 invoked from network); 16 Oct 2002 11:30:35 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Oct 2002 11:30:35 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2D151300B3D; Wed, 16 Oct 2002 21:30:32 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id F036B108F; Wed, 16 Oct 2002 21:30:32 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Geert Uytterhoeven Cc: Linux Kernel Development , linux-xfs@oss.sgi.com Subject: Re: XFS build error on m68k in 2.5.43 In-reply-to: Your message of "Wed, 16 Oct 2002 13:21:39 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 2002 21:30:27 +1000 Message-ID: <31054.1034767827@ocs3.intra.ocs.com.au> X-archive-position: 1004 X-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, 16 Oct 2002 13:21:39 +0200 (MEST), Geert Uytterhoeven wrote: > >When compiling a kernel for m68k (with CONFIG_XFS_FS=m), I get this error: > >| make -f fs/xfs/Makefile >| rm -f fs/xfs/built-in.o; m68k-linux-ar rcs fs/xfs/built-in.o >| m68k-linux-gcc -Wp,-MD,fs/xfs/linux/.xfs_stats.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -fno-strength-reduce -ffixed-a2 -nostdinc -iwithprefix include -DMODULE -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_stats -c -o fs/xfs/linux/xfs_stats.o fs/xfs/linux/xfs_stats.c >| In file included from fs/xfs/xfs.h:70, >| from fs/xfs/linux/xfs_stats.c:33: >| fs/xfs/xfs_bmap_btree.h:662: badly punctuated parameter list in `#define' >| fs/xfs/xfs_log.h:62: warning: `_lsn_cmp' defined but not used >| make[2]: *** [fs/xfs/linux/xfs_stats.o] Error 1 >| make[1]: *** [fs/xfs] Error 2 >| make: *** [fs] Error 2 > >Since it's not obvious to me what's wrong with that define, I'm asking here. Spot the typo :( --- fs/xfs/xfs_bmap_btree.h.orig Wed Oct 16 21:28:36 2002 +++ fs/xfs/xfs_bmap_btree.h Wed Oct 16 21:28:49 2002 @@ -658,8 +658,8 @@ #else #define xfs_bmbt_disk_set_all(r, s) \ xfs_bmbt_set_all(r, s) -#define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ - xfs_bmbt_set_allf(r, 0, b, c, v) +#define xfs_bmbt_disk_set_allf(r, o, b, c, v) \ + xfs_bmbt_set_allf(r, o, b, c, v) #endif void From owner-linux-xfs@oss.sgi.com Wed Oct 16 04:31:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 04:31:13 -0700 (PDT) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GBVAtG027703 for ; Wed, 16 Oct 2002 04:31:11 -0700 Received: (qmail 30941 invoked from network); 16 Oct 2002 11:31:04 -0000 Received: from laputa.namesys.com.7.16.212.in-addr.arpa (HELO laputa.namesys.com) (212.16.7.124) by thebsh.namesys.com with SMTP; 16 Oct 2002 11:31:04 -0000 Received: by laputa.namesys.com (Postfix on SuSE Linux 8.0 (i386), from userid 511) id 12E9A24B6C; Wed, 16 Oct 2002 15:31:04 +0400 (MSD) From: Nikita Danilov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15789.19959.929002.906160@laputa.namesys.com> Date: Wed, 16 Oct 2002 15:31:03 +0400 X-PGP-Fingerprint: 43CE 9384 5A1D CD75 5087 A876 A1AA 84D0 CCAA AC92 X-PGP-Key-ID: CCAAAC92 X-PGP-Key-At: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xCCAAAC92 To: Geert Uytterhoeven Cc: Linux Kernel Development , linux-xfs@oss.sgi.com Subject: Re: XFS build error on m68k in 2.5.43 In-Reply-To: References: X-Mailer: VM 7.07 under 21.5 (beta6) "bok choi" XEmacs Lucid Tomato: Beige X-archive-position: 1005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nikita@Namesys.COM Precedence: bulk X-list: linux-xfs Geert Uytterhoeven writes: > > When compiling a kernel for m68k (with CONFIG_XFS_FS=m), I get this error: > > | make -f fs/xfs/Makefile > | rm -f fs/xfs/built-in.o; m68k-linux-ar rcs fs/xfs/built-in.o > | m68k-linux-gcc -Wp,-MD,fs/xfs/linux/.xfs_stats.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -fno-strength-reduce -ffixed-a2 -nostdinc -iwithprefix include -DMODULE -Ifs/xfs -funsigned-char -DKBUILD_BASENAME=xfs_stats -c -o fs/xfs/linux/xfs_stats.o fs/xfs/linux/xfs_stats.c > | In file included from fs/xfs/xfs.h:70, > | from fs/xfs/linux/xfs_stats.c:33: > | fs/xfs/xfs_bmap_btree.h:662: badly punctuated parameter list in `#define' > | fs/xfs/xfs_log.h:62: warning: `_lsn_cmp' defined but not used > | make[2]: *** [fs/xfs/linux/xfs_stats.o] Error 1 > | make[1]: *** [fs/xfs] Error 2 > | make: *** [fs] Error 2 > > Since it's not obvious to me what's wrong with that define, I'm asking here. Second parameter of xfs_bmbt_disk_set_allf is 0 (zero). Try to replace it with O. > > Gr{oetje,eeting}s, > > Geert Nikita. > From owner-linux-xfs@oss.sgi.com Wed Oct 16 05:07:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 05:07:59 -0700 (PDT) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GC7utG031762 for ; Wed, 16 Oct 2002 05:07:56 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA18579; Wed, 16 Oct 2002 05:00:32 -0700 Date: Wed, 16 Oct 2002 05:00:31 -0700 (PDT) Message-Id: <20021016.050031.31945417.davem@redhat.com> To: Nikita@Namesys.COM Cc: geert@linux-m68k.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS build error on m68k in 2.5.43 From: "David S. Miller" In-Reply-To: <15789.19959.929002.906160@laputa.namesys.com> References: <15789.19959.929002.906160@laputa.namesys.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: linux-xfs From: Nikita Danilov Date: Wed, 16 Oct 2002 15:31:03 +0400 Second parameter of xfs_bmbt_disk_set_allf is 0 (zero). Try to replace it with O. You'll need lots more fixes ever after that, big-endian is pretty broke with the most recent updates. Here are the fixes I sent to the XFS maintainers. --- ./fs/xfs/linux/xfs_globals.c.~1~ Tue Oct 15 22:56:37 2002 +++ ./fs/xfs/linux/xfs_globals.c Tue Oct 15 22:57:18 2002 @@ -64,5 +64,6 @@ EXPORT_SYMBOL(xfs_Gqm); EXPORT_SYMBOL(xfs_next_bit); EXPORT_SYMBOL(xfs_contig_bits); EXPORT_SYMBOL(xfs_bmbt_get_all); +#if ARCH_CONVERT != ARCH_NOCONVERT EXPORT_SYMBOL(xfs_bmbt_disk_get_all); - +#endif --- ./fs/xfs/xfs_bmap_btree.h.~1~ Tue Oct 15 22:37:02 2002 +++ ./fs/xfs/xfs_bmap_btree.h Tue Oct 15 22:37:59 2002 @@ -658,8 +658,8 @@ xfs_bmbt_disk_set_allf( #else #define xfs_bmbt_disk_set_all(r, s) \ xfs_bmbt_set_all(r, s) -#define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ - xfs_bmbt_set_allf(r, 0, b, c, v) +#define xfs_bmbt_disk_set_allf(r, o, b, c, v) \ + xfs_bmbt_set_allf(r, o, b, c, v) #endif void --- ./fs/xfs/xfs_inode_item.c.~1~ Tue Oct 15 22:50:14 2002 +++ ./fs/xfs/xfs_inode_item.c Tue Oct 15 22:54:57 2002 @@ -214,7 +214,7 @@ xfs_inode_item_format( xfs_log_iovec_t *vecp; xfs_inode_t *ip; size_t data_bytes; - xfs_bmbt_rec_t *ext_buffer; + xfs_bmbt_rec_32_t *ext_buffer; int nrecs; xfs_mount_t *mp; @@ -340,7 +340,8 @@ xfs_inode_item_format( KM_SLEEP); iip->ili_extents_buf = ext_buffer; vecp->i_addr = (xfs_caddr_t)ext_buffer; - vecp->i_len = xfs_iextents_copy(ip, ext_buffer, + vecp->i_len = xfs_iextents_copy(ip, + (xfs_bmbt_rec_64_t *) ext_buffer, XFS_DATA_FORK); } ASSERT(vecp->i_len <= ip->i_df.if_bytes); --- ./fs/xfs/xfs_inode.c.~1~ Tue Oct 15 22:50:33 2002 +++ ./fs/xfs/xfs_inode.c Tue Oct 15 22:51:15 2002 @@ -602,9 +602,12 @@ xfs_iformat_extents( int whichfork) { xfs_ifork_t *ifp; - int nex, i; + int nex; int real_size; int size; +#if ARCH_CONVERT != ARCH_NOCONVERT + int i; +#endif xfs_bmbt_rec_t *ep, *dp; ifp = XFS_IFORK_PTR(ip, whichfork); From owner-linux-xfs@oss.sgi.com Wed Oct 16 05:15:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 05:15: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 g9GCFqtG000413 for ; Wed, 16 Oct 2002 05:15: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 HAA42765; Wed, 16 Oct 2002 07:15:47 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-32.corp.sgi.com [134.15.64.32]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA66912; Wed, 16 Oct 2002 07:15:45 -0500 (CDT) Subject: Re: XFS build error on m68k in 2.5.43 From: Stephen Lord To: "David S. Miller" Cc: Nikita@namesys.com, geert@linux-m68k.org, Linux Kernel Mailing List , linux-xfs@oss.sgi.com In-Reply-To: <20021016.050031.31945417.davem@redhat.com> References: <15789.19959.929002.906160@laputa.namesys.com> <20021016.050031.31945417.davem@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 07:11:58 -0500 Message-Id: <1034770320.1078.26.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1007 X-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-16 at 07:00, David S. Miller wrote: > From: Nikita Danilov > Date: Wed, 16 Oct 2002 15:31:03 +0400 > > Second parameter of xfs_bmbt_disk_set_allf is 0 (zero). Try to replace > it with O. > > You'll need lots more fixes ever after that, big-endian > is pretty broke with the most recent updates. > > Here are the fixes I sent to the XFS maintainers. > Thanks Dave, this all looks good, have to see if we a big endian box around here somewhere in future. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 07:11:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 07:11:05 -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 g9GEB0tG012894 for ; Wed, 16 Oct 2002 07:11:00 -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 HAA05378 for ; Wed, 16 Oct 2002 07:10:59 -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 g9GEA2fF001330 for ; Wed, 16 Oct 2002 16:10:02 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9GEA2UV001329 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 16:10:02 +0200 Date: Wed, 16 Oct 2002 16:10:02 +0200 Message-Id: <200210161410.g9GEA2UV001329@lab343.munich.sgi.com> Subject: TAKE - add synch I/O entry points To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 1008 X-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 Although we're not actually asynch yet we implement the AIO interface now. This is not different from all the other filesystems that use the generic_file_* rountines, which are still synch either. Unlike the simple filesystems that call directly into generic_file_* XFS will need updates to the inode locking to be actually async even after those are changed. Date: Wed Oct 16 07:10:18 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:130135a linux/fs/xfs/linux/xfs_file.c - 1.79 - implement linvfs_aio_read and linvfs_aio_write From owner-linux-xfs@oss.sgi.com Wed Oct 16 07:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 07:13:51 -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 g9GEDktG013582 for ; Wed, 16 Oct 2002 07:13:46 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 181ovh-000344-00 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 15:13:45 +0100 Date: Wed, 16 Oct 2002 15:13:45 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: TAKE - add Aynch I/O entry points Message-ID: <20021016151345.A11766@infradead.org> References: <200210161410.g9GEA2UV001329@lab343.munich.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210161410.g9GEA2UV001329@lab343.munich.sgi.com>; from hch@lab343.munich.sgi.com on Wed, Oct 16, 2002 at 04:10:02PM +0200 X-archive-position: 1009 X-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 Fixed the subject :) From owner-linux-xfs@oss.sgi.com Wed Oct 16 07:50:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 07:50: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 g9GEoZtG017122 for ; Wed, 16 Oct 2002 07:50:35 -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 JAA41881; Wed, 16 Oct 2002 09:50:27 -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 JAA25520; Wed, 16 Oct 2002 09:50:22 -0500 (CDT) Subject: Re: XFS 1.2Pre and nfs problem From: Eric Sandeen To: =?ISO-8859-1?Q?=DEeref?= Tufan =?ISO-8859-1?Q?=DEen?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021016115430.724d3b18.tufan@itu.edu.tr> References: <20021011124432.253ca55a.tufan@itu.edu.tr> <1034352726.1162.7.camel@rose.americas.sgi.com> <20021012140349.3c28bcc9.tufan@itu.edu.tr> <20021016115430.724d3b18.tufan@itu.edu.tr> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Oct 2002 09:46:58 -0500 Message-Id: <1034779623.15573.0.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 g9GEoZtG017130 X-archive-position: 1010 X-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 Did this generate any errors in your system logs? -Eric On Wed, 2002-10-16 at 03:54, 脼eref Tufan 脼en wrote: > Hi,,, > > I still have problems with nfs. I decided to run xfs_repair on my filesystems. On one of my fs xfs_repairs ends with the following error. I'm using XFS 1.2pre kernel and utilities.. > > The second xfs_repair ( for my second fs) is running now. If i get something wrong , I will let you know. > > Does anybody have any idea what can I do.. > > [root@lnxsrv2 /root]# tail /eski_disk/lnxsrv2.log > disconnected dir inode 421774644, moving to lost+found > disconnected dir inode 421774648, moving to lost+found > disconnected dir inode 421780236, moving to lost+found > disconnected dir inode 421789725, moving to lost+found > disconnected dir inode 421793356, moving to lost+found > disconnected dir inode 421793357, moving to lost+found > disconnected dir inode 421820974, moving to lost+found > Phase 7 - verify and correct link counts... > > fatal error -- couldn't map inode 68355923, err = 990 > > On Sat, 12 Oct 2002 14:03:49 +0300 > 艦eref Tufan 艦en wrote: > > > > > 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. > > > > > > > -- > > 艦eref Tufan 艦en > > 陌T脺-B陌DB > > Sistem Destek Grubu > > > > > > > -- > 艦eref Tufan 艦en > 陌T脺-B陌DB > Sistem Destek Grubu > > -- 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 16 07:54:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 07:54:37 -0700 (PDT) Received: from laptop.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GEsXtG017905 for ; Wed, 16 Oct 2002 07:54:34 -0700 Received: (from lord@localhost) by laptop.americas.sgi.com (8.11.6/8.11.6) id g9GEoW309901 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 09:50:32 -0500 Date: Wed, 16 Oct 2002 09:50:32 -0500 From: Stephen Lord Message-Id: <200210161450.g9GEoW309901@laptop.americas.sgi.com> Subject: TAKE - fix big endian build To: linux-xfs@oss.sgi.com X-archive-position: 1011 X-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 xfs build on big endian architectures and cleanup a couple of build warnings. Thanks to Dave Miller and Anton Blanchard for catching this. Steve Date: Wed Oct 16 07:52:30 PDT 2002 Workarea: cf-vpn-sw-corp-64-32.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:130142a linux/fs/xfs/xfs_inode_item.h - 1.41 - switch to 64 bit extent types in here, we were using them as such anyway. linux/fs/xfs/xfs_bmap_btree.h - 1.54 - fix xfs_bmbt_disk_set_allf definition on big endian boxes linux/fs/xfs/xfs_bmap_btree.c - 1.129 - kill a dead code path in the extent endian code. linux/fs/xfs/xfs_inode.c - 1.356 - fix unused var warning on big endian arch linux/fs/xfs/linux/xfs_globals.c - 1.38 - only export xfs_bmbt_disk_get_all on platforms where it is a function not a define From owner-linux-xfs@oss.sgi.com Wed Oct 16 08:06:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 08:06: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 g9GF6WtG019269 for ; Wed, 16 Oct 2002 08: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 KAA17393; Wed, 16 Oct 2002 10: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 KAA82787; Wed, 16 Oct 2002 10:06:25 -0500 (CDT) Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page()) From: Eric Sandeen To: Matteo Centonza Cc: Luben Tuikov , linux-xfs In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-keFEw6mbStm0VGy5GwtH" X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Oct 2002 10:03:01 -0500 Message-Id: <1034780582.15709.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1012 X-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 --=-keFEw6mbStm0VGy5GwtH Content-Type: text/plain Content-Transfer-Encoding: 7bit Could you guys try this patch, it should detect some stack overflows, in case that's what you're hitting... Meanwhile, perhaps we can set up a similar test here. -Eric On Wed, 2002-10-16 at 02:43, Matteo Centonza wrote: > Hi, > > > We have this scenario: > > > > xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD. > > > > our setup here differs only in having an IDE subsystem. In our case > xfs has internal log. > > > When md is set up with 3 (odd #) devices, then > > a mount sleeps indefinitely on down(), and when > > md is set up with 4 devices, then the kernel > > oopses at filemap.c:843 in unlock_page() the BUG() > > statement. > > > > The stack (of an SMP system) just prior to the > > oops is attached below. > > > > Our has 4 disks and hits the same kernel BUG with 2.4.19 (CVS as of > 20020806). Although i've lost the oops trace, i remember it was very > similar to this. > > > Now I've only been looking briefly at the code > > but have already noticed that _end_pagebuf_page_io_multi() > > does a unlock_page(), I'd guess for a good reason. > > It nevertheless breaks when set up with the above scenario. > > My guess would be that there's a wrong assumption somewhere. > > > > ((The same scenario, but with ext2 fs, doesn't oops.)) > > > We are currently stick to 2.4.18 (Release 1.1) and it works very well. > > Thanks, > > -m > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --=-keFEw6mbStm0VGy5GwtH Content-Disposition: attachment; filename=stackcheck.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=stackcheck.patch; charset=ISO-8859-1 --- linux/arch/i386/kernel/irq.c.org Thu Feb 28 14:05:56 2002 +++ linux/arch/i386/kernel/irq.c Fri Mar 1 12:40:37 2002 @@ -577,7 +577,17 @@ irq_desc_t *desc =3D irq_desc + irq; struct irqaction * action; unsigned int status; + long esp; =20 + /* Debugging check for stack overflow: is there less than 2KB free? */ + __asm__ __volatile__("andl %%esp,%0" : "=3Dr" (esp) : "0" (8191)); + if (esp < (sizeof(struct task_struct) + 2048)) { + printk("do_IRQ: stack overflow: %ld\n", + esp - sizeof(struct task_struct)); + __asm__ __volatile__("movl %%esp,%0" : "=3Dr" (esp)); + show_stack((void *)esp); + } +=09 kstat.irqs[cpu][irq]++; spin_lock(&desc->lock); desc->handler->ack(irq); --=-keFEw6mbStm0VGy5GwtH-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 09:28:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 09:28:27 -0700 (PDT) Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GGSKtG027314 for ; Wed, 16 Oct 2002 09:28:21 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id SAA23781; Wed, 16 Oct 2002 18:27:45 +0200 (MET DST) Date: Wed, 16 Oct 2002 18:27:46 +0200 (MEST) From: Geert Uytterhoeven To: "David S. Miller" cc: Nikita@Namesys.COM, Linux Kernel Development , linux-xfs@oss.sgi.com Subject: Re: XFS build error on m68k in 2.5.43 In-Reply-To: <20021016.050031.31945417.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-xfs On Wed, 16 Oct 2002, David S. Miller wrote: > From: Nikita Danilov > Date: Wed, 16 Oct 2002 15:31:03 +0400 > > Second parameter of xfs_bmbt_disk_set_allf is 0 (zero). Try to replace > it with O. > > You'll need lots more fixes ever after that, big-endian > is pretty broke with the most recent updates. > > Here are the fixes I sent to the XFS maintainers. Thanks! With these it compiles again on m68k, too. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-xfs@oss.sgi.com Wed Oct 16 09:32:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 09:32:53 -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 g9GGWotG028124 for ; Wed, 16 Oct 2002 09:32:50 -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 LAA75086; Wed, 16 Oct 2002 11:32:42 -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 LAA79302; Wed, 16 Oct 2002 11:32:41 -0500 (CDT) Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page()) From: Eric Sandeen To: Matteo Centonza Cc: Luben Tuikov , linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Oct 2002 11:29:16 -0500 Message-Id: <1034785757.16062.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1014 X-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 FWIW, I tried 3 and 4 LV devices in software raid 5, and both mounted successfully. This is with CVS code on an SMP system, with the LVM code that came from 2.4.19... Could you please file this bug in bugzilla, at http://oss.sgi.com/bugzilla/ ? Thanks, -Eric On Wed, 2002-10-16 at 02:43, Matteo Centonza wrote: > Hi, > > > We have this scenario: > > > > xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD. > > > > our setup here differs only in having an IDE subsystem. In our case > xfs has internal log. -- 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 16 11:01:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 11:01:17 -0700 (PDT) Received: from morpheus.matrix.com (213-99-179-60.uc.nombres.ttd.es [213.99.179.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GI17tG003729 for ; Wed, 16 Oct 2002 11:01:08 -0700 Received: (qmail 8099 invoked by uid 1000); 16 Oct 2002 18:01:50 -0000 From: yoros@wanadoo.es Date: Wed, 16 Oct 2002 20:01:50 +0200 To: linux-xfs Subject: Problems with "xfsdump" Message-ID: <20021016180150.GA8057@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, A few days ago, I posted a mail searching help with xfsdump and the dump-skip attribute in files created after the level 0 dump. I received no response to that mail. Did you received that mail? Please mail me if you know of where is the problem. I think this is a developer list for XFS. Is there another list for XFS-users? (like debian-user) ? Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9ramOWIvihXTx06wRAu8+AKCIeV4MSyYEQu42h8XLSgj/4AWUpgCeI8Sx lUfblw8UcIjY/7/tR9Ki1rA= =CLS2 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 11:05:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 11:05: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 g9GI5DtG004529 for ; Wed, 16 Oct 2002 11:05:13 -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 NAA36193; Wed, 16 Oct 2002 13:05:08 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA07076; Wed, 16 Oct 2002 13:05:07 -0500 (CDT) Subject: Re: Problems with "xfsdump" From: Stephen Lord To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021016180150.GA8057@morpheus.matrix.com> References: <20021016180150.GA8057@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 13:01:07 -0500 Message-Id: <1034791268.1107.4.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1016 X-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-16 at 13:01, yoros@wanadoo.es wrote: > > Hi, > > A few days ago, I posted a mail searching help with xfsdump and the > dump-skip attribute in files created after the level 0 dump. I received > no response to that mail. Did you received that mail? > > Please mail me if you know of where is the problem. > > I think this is a developer list for XFS. Is there another list for > XFS-users? (like debian-user) ? > > Pedro > Hi Pedro, Your mail was received, xfsdump is a bit in limbo right now, there is no one assigned to look at it right now. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 11:22:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 11:22:45 -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 g9GIMhtG006361 for ; Wed, 16 Oct 2002 11:22:43 -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 NAA07855; Wed, 16 Oct 2002 13:22:37 -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 NAA81734; Wed, 16 Oct 2002 13:22:36 -0500 (CDT) Subject: Re: Problems with "xfsdump" From: Eric Sandeen To: Stephen Lord Cc: yoros@wanadoo.es, linux-xfs In-Reply-To: <1034791268.1107.4.camel@laptop.americas.sgi.com> References: <20021016180150.GA8057@morpheus.matrix.com> <1034791268.1107.4.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: 16 Oct 2002 13:19:11 -0500 Message-Id: <1034792351.15573.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1017 X-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 Pedro, can you file the bug in http://oss.sgi.com/bugzilla/? At least that way it won't get lost. -ERic On Wed, 2002-10-16 at 13:01, Stephen Lord wrote: > On Wed, 2002-10-16 at 13:01, yoros@wanadoo.es wrote: > > > > Hi, > > > > A few days ago, I posted a mail searching help with xfsdump and the > > dump-skip attribute in files created after the level 0 dump. I received > > no response to that mail. Did you received that mail? > > > > Please mail me if you know of where is the problem. > > > > I think this is a developer list for XFS. Is there another list for > > XFS-users? (like debian-user) ? > > > > Pedro > > > > Hi Pedro, > > Your mail was received, xfsdump is a bit in limbo right now, there is > no one assigned to look at it right now. > > 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 Wed Oct 16 11:55:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 11:55:53 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GItktG009721 for ; Wed, 16 Oct 2002 11:55:46 -0700 Received: (qmail 7973 invoked by uid 500); 16 Oct 2002 18:55:15 -0000 Subject: Hard Server Lockups [was Re: Request for known XFS bugs.] From: Austin Gonyou To: Seth Mos Cc: linux-xfs@oss.sgi.com, andrea@suse.de In-Reply-To: <20021016100602.V88870-100000@xs1.xs4all.nl> References: <20021016100602.V88870-100000@xs1.xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HVW+7ln6HgjnzdVBuqAX" Organization: Coremetrics, Inc. Message-Id: <1034794514.7259.86.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 16 Oct 2002 13:55:15 -0500 X-archive-position: 1018 X-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 --=-HVW+7ln6HgjnzdVBuqAX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-10-16 at 03:12, Seth Mos wrote: > On 15 Oct 2002, Austin Gonyou wrote: >=20 > > I don't know if the issue is XFS, but I don't know it's *not* > either. > > The server stats right now, are that I have two Dell 6650's with 8GB > > ram, RH 7.2 from the xfs 1.1 installer base, with most recent redhat > > updates, QLogic 2300Fs atached to ~1TB - 3TB of FC2 storage using > LVM > > for volume management. Lets start here, right here. I got a message last night from Michael Clark on the LKML which described a very similar configuration to the above.=20 > Does the box use interrupt sharing? There are also a lot of people on > linux-poweredge@dell.com that see interrupt only handled by the first > processor. >=20 > > The symptoms are that after about 6 days of uptime with loadavg > ~10-12% > > most of the time, running oracle8i and some other apps we have, the > box > > locks. The symptoms described above seem to be an interaction of the kernel stack useage with LVM, Qlogic drivers, and a journaling FS. I see the problem using XFS, he sees the problem using RHAS with EXT3. Both kernels have LVM. His solution, so far, was to remove LVM from the mix and now has >17 days uptime, or since his last boot. This is more noted by the fact that the only volumes which needed repair, and have their log dumped entirely, are those volumes under LVM control.=20 It is yet unknown whether LVM2 or EVMS interactions show similar symptoms with the described configuration. --=20 Austin Gonyou Coremetrics, Inc. --=-HVW+7ln6HgjnzdVBuqAX 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 iD8DBQA9rbYS94g6ZVmFMoIRAsVpAJ4/UCKTSR0YqrMbi9ngAAG1EfnPjgCfeM3L EEq2LGu7up/c7Tnezs0HYwo= =fEth -----END PGP SIGNATURE----- --=-HVW+7ln6HgjnzdVBuqAX-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 13:04:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 13:04:06 -0700 (PDT) Received: from morpheus.matrix.com (213-99-179-60.uc.nombres.ttd.es [213.99.179.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GK3ttG017054 for ; Wed, 16 Oct 2002 13:03:57 -0700 Received: (qmail 8510 invoked by uid 1000); 16 Oct 2002 20:04:38 -0000 From: yoros@wanadoo.es Date: Wed, 16 Oct 2002 22:04:38 +0200 To: linux-xfs Subject: Re: Problems with "xfsdump" Message-ID: <20021016200438.GA8459@morpheus.matrix.com> References: <20021016180150.GA8057@morpheus.matrix.com> <1034791268.1107.4.camel@laptop.americas.sgi.com> <1034792351.15573.28.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <1034792351.15573.28.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 01:19:11PM -0500, Eric Sandeen wrote: > Pedro, can you file the bug in http://oss.sgi.com/bugzilla/? At least > that way it won't get lost. >=20 > -ERic >=20 > On Wed, 2002-10-16 at 13:01, Stephen Lord wrote: > > On Wed, 2002-10-16 at 13:01, yoros@wanadoo.es wrote: > > >=20 > > > Hi, > > >=20 > > > A few days ago, I posted a mail searching help with xfsdump and the > > > dump-skip attribute in files created after the level 0 dump. I receiv= ed > > > no response to that mail. Did you received that mail? > > >=20 > > > Please mail me if you know of where is the problem. > > >=20 > > > I think this is a developer list for XFS. Is there another list for > > > XFS-users? (like debian-user) ? > > >=20 > > > Pedro > > >=20 > >=20 > > Hi Pedro, > >=20 > > Your mail was received, xfsdump is a bit in limbo right now, there is > > no one assigned to look at it right now. > >=20 > > Steve > >=20 > > OK, thank you both. I will send a bug-report to that. I hope that this "problem" (if it is) could be repaired. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9rcZWWIvihXTx06wRAs6+AKCFV095DzkmByKC8oHjO+TL8DduwgCfaJLg w4T0MCbTbhqh+b50+Xe4nQc= =9AWW -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 13:13:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 13:13: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 g9GKCxtG018332 for ; Wed, 16 Oct 2002 13:12: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 PAA88642 for ; Wed, 16 Oct 2002 15:12: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 PAA24735 for ; Wed, 16 Oct 2002 15:12:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9GKACv15549; Wed, 16 Oct 2002 15:10:12 -0500 Message-Id: <200210162010.g9GKACv15549@jen.americas.sgi.com> Date: Wed, 16 Oct 2002 15:10:12 -0500 Subject: TAKE - merge up to 2.5.43 To: linux-xfs@oss.sgi.com X-archive-position: 1020 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Oct 16 13:06:23 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:130187a linux/drivers/mtd/cmdline.c - 1.1 linux/sound/usb/usbmixer_maps.c - 1.1 linux/fs/nfs/nfs4xdr.c - 1.1 linux/Documentation/arm/XScale/ADIFCC/80200EVB - 1.1 linux/Documentation/arm/XScale/IOP310/IQ80310 - 1.1 linux/Documentation/filesystems/afs.txt - 1.1 linux/fs/afs/mount.h - 1.1 linux/drivers/mtd/maps/autcpu12-nvram.c - 1.1 linux/fs/afs/proc.c - 1.1 linux/drivers/mtd/maps/ceiva.c - 1.1 linux/drivers/mtd/maps/edb7312.c - 1.1 linux/drivers/mtd/maps/epxa10db-flash.c - 1.1 linux/drivers/mtd/maps/fortunet.c - 1.1 linux/include/linux/rcupdate.h - 1.1 linux/net/rxrpc/transport.c - 1.1 linux/net/rxrpc/sysctl.c - 1.1 linux/net/rxrpc/rxrpc_syms.c - 1.1 linux/net/rxrpc/proc.c - 1.1 linux/drivers/mtd/maps/impa7.c - 1.1 linux/drivers/mtd/maps/pci.c - 1.1 linux/drivers/mtd/maps/pcmciamtd.c - 1.1 linux/drivers/mtd/mtdconcat.c - 1.1 linux/drivers/oprofile/buffer_sync.c - 1.1 linux/net/rxrpc/peer.c - 1.1 linux/drivers/oprofile/buffer_sync.h - 1.1 linux/drivers/oprofile/cpu_buffer.c - 1.1 linux/drivers/oprofile/cpu_buffer.h - 1.1 linux/net/rxrpc/main.c - 1.1 linux/drivers/oprofile/event_buffer.c - 1.1 linux/drivers/oprofile/event_buffer.h - 1.1 linux/drivers/oprofile/oprof.c - 1.1 linux/drivers/oprofile/oprof.h - 1.1 linux/drivers/oprofile/oprofile_files.c - 1.1 linux/drivers/oprofile/oprofile_stats.c - 1.1 linux/drivers/oprofile/oprofile_stats.h - 1.1 linux/drivers/oprofile/oprofilefs.c - 1.1 linux/net/rxrpc/krxtimod.c - 1.1 linux/net/rxrpc/krxsecd.c - 1.1 linux/net/rxrpc/krxiod.c - 1.1 linux/net/rxrpc/internal.h - 1.1 linux/drivers/serial/8250_acorn.c - 1.1 linux/fs/afs/Makefile - 1.1 linux/fs/afs/cache-layout.h - 1.1 linux/fs/afs/callback.c - 1.1 linux/net/rxrpc/connection.c - 1.1 linux/drivers/char/tipar.c - 1.1 linux/net/rxrpc/call.c - 1.1 linux/net/rxrpc/Makefile - 1.1 linux/fs/afs/cell.c - 1.1 linux/fs/afs/cell.h - 1.1 linux/fs/afs/cmservice.c - 1.1 linux/fs/afs/cmservice.h - 1.1 linux/fs/afs/dir.c - 1.1 linux/fs/afs/errors.h - 1.1 linux/arch/i386/mach-summit/mach_apic.h - 1.1 linux/fs/afs/file.c - 1.1 linux/fs/afs/fsclient.c - 1.1 linux/include/linux/mtd/concat.h - 1.1 linux/include/asm-x86_64/proto.h - 1.1 linux/include/linux/dcookies.h - 1.1 linux/include/asm-x86_64/sections.h - 1.1 linux/include/asm-x86_64/pci-direct.h - 1.1 linux/include/asm-x86_64/acpi.h - 1.1 linux/arch/x86_64/boot/compressed/vmlinux.scr - 1.1 linux/include/asm-i386/nmi.h - 1.1 linux/fs/afs/fsclient.h - 1.1 linux/fs/afs/inode.c - 1.1 linux/include/rxrpc/call.h - 1.1 linux/fs/afs/internal.h - 1.1 linux/include/rxrpc/connection.h - 1.1 linux/include/rxrpc/krxiod.h - 1.1 linux/include/rxrpc/krxsecd.h - 1.1 linux/include/rxrpc/krxtimod.h - 1.1 linux/include/rxrpc/message.h - 1.1 linux/include/rxrpc/packet.h - 1.1 linux/include/rxrpc/peer.h - 1.1 linux/fs/afs/kafsasyncd.c - 1.1 linux/fs/afs/kafsasyncd.h - 1.1 linux/fs/afs/kafstimod.c - 1.1 linux/include/rxrpc/rxrpc.h - 1.1 linux/include/rxrpc/transport.h - 1.1 linux/fs/afs/kafstimod.h - 1.1 linux/fs/afs/main.c - 1.1 linux/fs/afs/misc.c - 1.1 linux/fs/afs/mntpt.c - 1.1 linux/include/rxrpc/types.h - 1.1 linux/fs/afs/vnode.c - 1.1 linux/arch/i386/kernel/profile.c - 1.1 linux/fs/afs/vnode.h - 1.1 linux/arch/i386/oprofile/op_counter.h - 1.1 linux/fs/afs/volume.c - 1.1 linux/fs/nfs/nfs4state.c - 1.1 linux/kernel/rcupdate.c - 1.1 linux/arch/i386/mach-generic/mach_apic.h - 1.1 linux/arch/x86_64/kernel/pci-nommu.c - 1.1 linux/include/linux/oprofile.h - 1.1 linux/net/ipv4/ip_proc.c - 1.1 linux/arch/i386/oprofile/Config.help - 1.1 linux/arch/i386/oprofile/Config.in - 1.1 linux/arch/i386/oprofile/Makefile - 1.1 linux/arch/i386/oprofile/init.c - 1.1 linux/arch/i386/oprofile/nmi_int.c - 1.1 linux/fs/nfs/nfs4renewd.c - 1.1 linux/arch/i386/oprofile/op_model_athlon.c - 1.1 linux/arch/i386/oprofile/op_model_ppro.c - 1.1 linux/arch/i386/oprofile/op_x86_model.h - 1.1 linux/arch/i386/oprofile/timer_int.c - 1.1 linux/include/linux/nfs4_mount.h - 1.1 linux/drivers/block/scsi_ioctl.c - 1.1 linux/arch/um/kernel/tempfile.c - 1.1 linux/fs/intermezzo/replicator.c - 1.1 linux/arch/x86_64/kernel/pci-gart.c - 1.1 linux/fs/afs/volume.h - 1.1 linux/include/asm-x86_64/rtc.h - 1.1 linux/include/asm-x86_64/rmap.h - 1.1 linux/arch/um/include/tempfile.h - 1.1 linux/drivers/block/ioctl.c - 1.1 linux/fs/afs/super.c - 1.1 linux/fs/dcookies.c - 1.1 linux/arch/x86_64/lib/bitstr.c - 1.1 linux/fs/afs/vlclient.h - 1.1 linux/arch/x86_64/kernel/e820.c - 1.1 linux/fs/nfs/nfs4proc.c - 1.1 linux/arch/x86_64/kernel/reboot.c - 1.1 linux/fs/afs/vlocation.c - 1.1 linux/fs/intermezzo/kml_unpack.c - 1.1 linux/arch/x86_64/kernel/aperture.c - 1.1 linux/arch/x86_64/kernel/acpi.c - 1.1 linux/fs/afs/server.h - 1.1 linux/fs/afs/server.c - 1.1 linux/include/asm-arm/numnodes.h - 1.1 linux/arch/sparc64/lib/ipcsum.S - 1.1 linux/fs/intermezzo/journal_tmpfs.c - 1.1 linux/fs/intermezzo/fileset.c - 1.1 linux/fs/afs/super.h - 1.1 linux/fs/afs/types.h - 1.1 linux/fs/afs/transport.h - 1.1 linux/fs/afs/vlclient.c - 1.1 linux/net/x25/af_x25.c - 1.32 linux/net/unix/af_unix.c - 1.49 linux/net/socket.c - 1.44 linux/net/sched/cls_route.c - 1.8 linux/net/rose/af_rose.c - 1.28 linux/net/packet/af_packet.c - 1.36 linux/net/netrom/af_netrom.c - 1.27 linux/net/netlink/af_netlink.c - 1.21 linux/net/irda/af_irda.c - 1.42 linux/net/ipx/af_ipx.c - 1.32 linux/net/ipv6/udp.c - 1.33 linux/net/ipv6/sit.c - 1.25 linux/net/ipv6/route.c - 1.24 linux/net/ipv6/raw.c - 1.29 linux/net/ipv6/ip6_fw.c - 1.7 linux/net/ipv6/ip6_fib.c - 1.13 linux/net/ipv6/Makefile - 1.8 linux/net/ipv6/Config.in - 1.8 linux/net/ipv4/udp.c - 1.33 linux/net/ipv4/tcp_timer.c - 1.26 linux/net/ipv4/tcp_ipv4.c - 1.51 linux/net/ipv4/tcp_input.c - 1.44 linux/net/ipv4/tcp.c - 1.45 linux/net/ipv4/sysctl_net_ipv4.c - 1.15 linux/net/ipv4/syncookies.c - 1.16 linux/net/ipv4/route.c - 1.37 linux/net/ipv4/raw.c - 1.25 linux/net/ipv4/ipmr.c - 1.24 linux/net/ipv4/ipip.c - 1.25 linux/net/ipv4/ip_output.c - 1.36 linux/net/ipv4/ip_nat_dumb.c - 1.6 linux/net/ipv4/ip_gre.c - 1.24 linux/net/ipv4/igmp.c - 1.20 linux/net/ipv4/icmp.c - 1.33 linux/net/ipv4/fib_semantics.c - 1.11 linux/net/ipv4/fib_rules.c - 1.10 linux/net/ipv4/fib_hash.c - 1.6 linux/net/ipv4/fib_frontend.c - 1.15 linux/net/ipv4/arp.c - 1.25 linux/net/ipv4/af_inet.c - 1.42 linux/net/ipv4/Makefile - 1.12 linux/net/core/sock.c - 1.29 linux/net/ax25/af_ax25.c - 1.28 linux/net/appletalk/ddp.c - 1.25 linux/net/Makefile - 1.27 linux/mm/vmscan.c - 1.117 linux/mm/swap.c - 1.28 linux/mm/page_alloc.c - 1.97 linux/mm/mmap.c - 1.63 linux/mm/memory.c - 1.96 linux/mm/filemap.c - 1.139 linux/kernel/sysctl.c - 1.60 linux/kernel/sys.c - 1.43 linux/kernel/sched.c - 1.87 linux/kernel/ksyms.c - 1.171 linux/kernel/exit.c - 1.57 linux/kernel/Makefile - 1.38 linux/init/main.c - 1.93 linux/include/net/udp.h - 1.9 linux/include/net/tcp.h - 1.37 linux/include/net/sock.h - 1.36 linux/include/net/route.h - 1.18 linux/include/net/ip_fib.h - 1.7 linux/include/net/ip6_fw.h - 1.3 linux/include/net/ip6_fib.h - 1.5 linux/include/net/ip.h - 1.19 linux/include/net/inet_common.h - 1.6 linux/include/net/flow.h - 1.3 linux/include/net/arp.h - 1.4 linux/include/linux/videodev.h - 1.23 linux/include/linux/tty_driver.h - 1.4 linux/include/linux/tcp.h - 1.12 linux/include/linux/sysctl.h - 1.63 linux/include/linux/swap.h - 1.67 linux/include/linux/sched.h - 1.88 linux/include/linux/nfs_mount.h - 1.6 linux/include/linux/nfs_fs_sb.h - 1.9 linux/include/linux/nfs_fs.h - 1.28 linux/include/linux/nfs3.h - 1.6 linux/include/linux/nfs.h - 1.8 linux/include/linux/net.h - 1.11 linux/include/linux/msdos_fs_sb.h - 1.10 linux/include/linux/module.h - 1.37 linux/include/linux/mm.h - 1.104 linux/include/linux/genhd.h - 1.28 linux/include/linux/fs.h - 1.195 linux/include/linux/dcache.h - 1.29 linux/include/linux/cdrom.h - 1.24 linux/include/linux/blkdev.h - 1.74 linux/include/asm-sparc64/semaphore.h - 1.10 linux/include/asm-sparc64/irq.h - 1.15 linux/include/asm-sparc64/checksum.h - 1.10 linux/include/asm-i386/unistd.h - 1.29 linux/include/asm-i386/smp.h - 1.23 linux/include/asm-i386/msr.h - 1.15 linux/include/asm-arm/procinfo.h - 1.12 linux/include/asm-arm/processor.h - 1.25 linux/include/asm-arm/proc-armo/system.h - 1.12 linux/include/asm-arm/pgtable.h - 1.29 linux/include/asm-arm/page.h - 1.19 linux/include/asm-arm/ide.h - 1.8 linux/include/asm-arm/hardirq.h - 1.13 linux/include/asm-arm/ecard.h - 1.4 linux/include/asm-arm/arch-rpc/uncompress.h - 1.5 linux/include/asm-arm/arch-rpc/serial.h - 1.5 linux/include/asm-arm/arch-rpc/ide.h - 1.6 linux/include/asm-arm/arch-ebsa285/time.h - 1.14 linux/include/asm-alpha/posix_types.h - 1.6 linux/include/asm-alpha/mmu_context.h - 1.15 linux/include/asm-alpha/elf.h - 1.6 linux/fs/vfat/namei.c - 1.36 linux/fs/smbfs/sock.c - 1.16 linux/fs/qnx4/inode.c - 1.39 linux/fs/qnx4/file.c - 1.12 linux/fs/qnx4/dir.c - 1.15 linux/fs/proc/proc_tty.c - 1.8 linux/fs/open.c - 1.43 linux/fs/nfsd/export.c - 1.42 linux/fs/nfs/proc.c - 1.18 linux/fs/nfs/nfs3xdr.c - 1.18 linux/fs/nfs/nfs2xdr.c - 1.21 linux/fs/nfs/inode.c - 1.56 linux/fs/nfs/file.c - 1.38 linux/fs/nfs/Makefile - 1.10 linux/fs/msdos/namei.c - 1.34 linux/fs/inode.c - 1.85 linux/fs/file_table.c - 1.24 linux/fs/fcntl.c - 1.28 linux/fs/fat/inode.c - 1.50 linux/fs/ext2/inode.c - 1.57 linux/fs/ext2/ialloc.c - 1.30 linux/fs/exec.c - 1.70 linux/fs/dquot.c - 1.63 linux/fs/dcache.c - 1.43 linux/fs/buffer.c - 1.139 linux/fs/block_dev.c - 1.65 linux/fs/Makefile - 1.71 linux/fs/Config.in - 1.100 linux/drivers/video/acornfb.c - 1.27 linux/drivers/scsi/sym53c8xx.h - 1.10 linux/drivers/scsi/sym53c8xx.c - 1.35 linux/drivers/scsi/sym53c416.c - 1.13 linux/drivers/scsi/st.h - 1.17 linux/drivers/scsi/st.c - 1.54 linux/drivers/scsi/sr_vendor.c - 1.14 linux/drivers/scsi/sr_ioctl.c - 1.28 linux/drivers/scsi/sr.h - 1.10 linux/drivers/scsi/sr.c - 1.55 linux/drivers/scsi/sg.c - 1.40 linux/drivers/scsi/sd.c - 1.75 linux/drivers/scsi/scsi_syms.c - 1.21 linux/drivers/scsi/scsi_ioctl.c - 1.25 linux/drivers/scsi/scsi_error.c - 1.32 linux/drivers/scsi/scsi.h - 1.36 linux/drivers/scsi/scsi.c - 1.62 linux/drivers/scsi/pluto.h - 1.4 linux/drivers/scsi/pluto.c - 1.14 linux/drivers/scsi/ncr53c8xx.h - 1.6 linux/drivers/scsi/ncr53c8xx.c - 1.27 linux/drivers/scsi/hosts.h - 1.27 linux/drivers/scsi/hosts.c - 1.33 linux/drivers/scsi/fcal.h - 1.4 linux/drivers/scsi/fcal.c - 1.10 linux/drivers/scsi/esp.c - 1.25 linux/drivers/scsi/eata.h - 1.12 linux/drivers/scsi/eata.c - 1.27 linux/drivers/scsi/advansys.h - 1.8 linux/drivers/scsi/advansys.c - 1.29 linux/drivers/scsi/NCR5380.c - 1.12 linux/drivers/scsi/BusLogic.h - 1.10 linux/drivers/scsi/BusLogic.c - 1.19 linux/drivers/char/tty_io.c - 1.56 linux/drivers/char/synclink.c - 1.29 linux/drivers/char/rtc.c - 1.32 linux/drivers/char/n_hdlc.c - 1.16 linux/drivers/char/Makefile - 1.75 linux/drivers/char/Config.in - 1.68 linux/drivers/cdrom/sonycd535.c - 1.31 linux/drivers/cdrom/sjcd.c - 1.24 linux/drivers/cdrom/sbpcd.c - 1.31 linux/drivers/cdrom/optcd.c - 1.25 linux/drivers/cdrom/mcdx.c - 1.22 linux/drivers/cdrom/mcd.c - 1.25 linux/drivers/cdrom/gscd.c - 1.25 linux/drivers/cdrom/cm206.c - 1.26 linux/drivers/cdrom/cdu31a.c - 1.25 linux/drivers/cdrom/cdrom.c - 1.49 linux/drivers/cdrom/aztcd.c - 1.27 linux/drivers/block/z2ram.c - 1.21 linux/drivers/block/xd.c - 1.48 linux/drivers/block/swim3.c - 1.23 linux/drivers/block/rd.c - 1.64 linux/drivers/block/ps2esdi.c - 1.51 linux/drivers/block/paride/pf.c - 1.32 linux/drivers/block/paride/pd.c - 1.40 linux/drivers/block/paride/pcd.c - 1.28 linux/drivers/block/nbd.c - 1.46 linux/drivers/block/loop.c - 1.71 linux/drivers/block/ll_rw_blk.c - 1.119 linux/drivers/block/genhd.c - 1.38 linux/drivers/block/floppy.c - 1.55 linux/drivers/block/ataflop.c - 1.30 linux/drivers/block/amiflop.c - 1.31 linux/drivers/block/acsi.c - 1.40 linux/drivers/block/Makefile - 1.30 linux/drivers/block/Config.in - 1.40 linux/drivers/acorn/scsi/queue.h - 1.5 linux/drivers/acorn/scsi/queue.c - 1.7 linux/drivers/acorn/scsi/oak.c - 1.13 linux/drivers/acorn/scsi/fas216.h - 1.6 linux/drivers/acorn/scsi/fas216.c - 1.14 linux/drivers/acorn/scsi/ecoscsi.c - 1.14 linux/drivers/acorn/scsi/cumana_1.c - 1.11 linux/drivers/acorn/scsi/acornscsi.h - 1.8 linux/drivers/acorn/scsi/acornscsi.c - 1.19 linux/drivers/acorn/net/etherh.c - 1.18 linux/drivers/acorn/net/ether3.c - 1.15 linux/drivers/acorn/net/ether1.c - 1.15 linux/drivers/acorn/char/serial-dualsp.c - 1.6 linux/drivers/acorn/char/serial-card.c - 1.9 linux/drivers/acorn/char/serial-atomwide.c - 1.6 linux/drivers/acorn/char/mouse_rpc.c - 1.10 linux/drivers/acorn/char/keyb_ps2.c - 1.11 linux/drivers/acorn/char/Makefile - 1.15 linux/drivers/acorn/block/mfmhd.c - 1.33 linux/drivers/acorn/block/fd1772.c - 1.24 linux/drivers/Makefile - 1.38 linux/arch/sparc64/mm/fault.c - 1.25 linux/arch/sparc64/lib/Makefile - 1.13 linux/arch/sparc64/kernel/unaligned.c - 1.10 linux/arch/sparc64/kernel/sys_sparc32.c - 1.61 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.49 linux/arch/sparc64/kernel/signal32.c - 1.29 linux/arch/sparc64/kernel/ebus.c - 1.18 linux/arch/sparc64/defconfig - 1.81 linux/arch/sparc/kernel/time.c - 1.21 linux/arch/sparc/kernel/pcic.c - 1.24 linux/arch/m68k/atari/stram.c - 1.21 linux/arch/i386/kernel/traps.c - 1.64 linux/arch/i386/kernel/time.c - 1.30 linux/arch/i386/kernel/ldt.c - 1.15 linux/arch/i386/kernel/io_apic.c - 1.46 linux/arch/i386/kernel/i386_ksyms.c - 1.59 linux/arch/i386/kernel/entry.S - 1.65 linux/arch/i386/kernel/Makefile - 1.38 linux/arch/i386/config.in - 1.96 linux/arch/i386/Makefile - 1.35 linux/arch/arm/mm/mm-armv.c - 1.30 linux/arch/arm/mm/init.c - 1.34 linux/arch/arm/mm/fault-armv.c - 1.28 linux/arch/arm/kernel/traps.c - 1.30 linux/arch/arm/kernel/time.c - 1.18 linux/arch/arm/kernel/signal.c - 1.27 linux/arch/arm/kernel/setup.c - 1.36 linux/arch/arm/kernel/ptrace.c - 1.22 linux/arch/arm/kernel/process.c - 1.31 linux/arch/arm/kernel/entry-armv.S - 1.36 linux/arch/arm/kernel/ecard.c - 1.22 linux/arch/arm/config.in - 1.47 linux/arch/arm/boot/compressed/head.S - 1.22 linux/arch/arm/boot/compressed/Makefile - 1.24 linux/arch/arm/Makefile - 1.35 linux/arch/alpha/lib/stxncpy.S - 1.7 linux/arch/alpha/kernel/sys_takara.c - 1.10 linux/arch/alpha/kernel/sys_sx164.c - 1.12 linux/arch/alpha/kernel/sys_sio.c - 1.15 linux/arch/alpha/kernel/sys_sable.c - 1.11 linux/arch/alpha/kernel/sys_rx164.c - 1.11 linux/arch/alpha/kernel/sys_ruffian.c - 1.14 linux/arch/alpha/kernel/sys_rawhide.c - 1.14 linux/arch/alpha/kernel/sys_noritake.c - 1.11 linux/arch/alpha/kernel/sys_mikasa.c - 1.12 linux/arch/alpha/kernel/sys_miata.c - 1.14 linux/arch/alpha/kernel/sys_jensen.c - 1.12 linux/arch/alpha/kernel/sys_eb64p.c - 1.10 linux/arch/alpha/kernel/sys_dp264.c - 1.19 linux/arch/alpha/kernel/sys_cabriolet.c - 1.15 linux/arch/alpha/kernel/sys_alcor.c - 1.12 linux/arch/alpha/kernel/setup.c - 1.32 linux/arch/alpha/kernel/irq.c - 1.25 linux/Makefile - 1.224 linux/MAINTAINERS - 1.122 linux/Documentation/sysctl/vm.txt - 1.10 linux/Documentation/filesystems/vfat.txt - 1.7 linux/Documentation/Changes - 1.58 linux/net/decnet/af_decnet.c - 1.34 linux/include/linux/blkpg.h - 1.4 linux/drivers/video/cyber2000fb.h - 1.14 linux/drivers/video/cyber2000fb.c - 1.36 linux/drivers/block/blkpg.c - 1.30 linux/arch/arm/boot/compressed/ll_char_wr.S - 1.5 linux/Documentation/kernel-parameters.txt - 1.19 linux/drivers/tc/zs.c - 1.10 linux/drivers/block/cpqarray.c - 1.60 linux/fs/iobuf.c - 1.24 linux/include/linux/iobuf.h - 1.17 linux/include/asm-i386/hw_irq.h - 1.30 linux/fs/partitions/check.c - 1.56 linux/net/core/netfilter.c - 1.16 linux/net/atm/common.h - 1.4 linux/net/atm/common.c - 1.18 linux/net/atm/clip.c - 1.14 linux/arch/arm/kernel/bios32.c - 1.30 linux/arch/alpha/kernel/pci.c - 1.24 linux/drivers/block/DAC960.c - 1.59 linux/arch/sparc64/kernel/semaphore.c - 1.10 linux/arch/sparc64/kernel/pci_impl.h - 1.9 linux/arch/sparc64/kernel/pci.c - 1.31 linux/arch/sh/kernel/setup.c - 1.21 linux/drivers/scsi/ips.h - 1.16 linux/drivers/scsi/ips.c - 1.31 linux/drivers/char/n_r3964.c - 1.15 linux/drivers/pcmcia/ricoh.h - 1.6 linux/drivers/pcmcia/bulkmem.c - 1.15 linux/drivers/block/swim_iop.c - 1.18 linux/Documentation/filesystems/proc.txt - 1.13 linux/arch/i386/kernel/smpboot.c - 1.50 linux/drivers/net/wan/syncppp.c - 1.16 linux/include/asm-arm/pci.h - 1.21 linux/include/asm-arm/arch-sa1100/irqs.h - 1.12 linux/fs/proc/proc_misc.c - 1.46 linux/drivers/video/acornfb.h - 1.6 linux/include/asm-arm/pgalloc.h - 1.12 linux/arch/alpha/kernel/sys_nautilus.c - 1.9 linux/arch/alpha/kernel/sys_eiger.c - 1.8 linux/kernel/timer.c - 1.34 linux/drivers/scsi/scsi_lib.c - 1.51 linux/drivers/sbus/char/jsflash.c - 1.25 linux/drivers/ieee1394/raw1394.h - 1.5 linux/drivers/ieee1394/raw1394.c - 1.21 linux/drivers/ieee1394/ieee1394_core.h - 1.15 linux/drivers/ieee1394/pcilynx.c - 1.24 linux/drivers/ieee1394/ieee1394_core.c - 1.24 linux/drivers/ieee1394/ohci1394.c - 1.25 linux/drivers/ieee1394/ieee1394_types.h - 1.15 linux/drivers/ieee1394/ieee1394_transactions.h - 1.5 linux/drivers/ieee1394/ieee1394_transactions.c - 1.12 linux/drivers/ieee1394/csr.h - 1.4 linux/arch/i386/kernel/apic.c - 1.37 linux/drivers/ieee1394/hosts.h - 1.12 linux/drivers/ieee1394/hosts.c - 1.14 linux/drivers/ieee1394/highlevel.h - 1.5 linux/arch/i386/kernel/mpparse.c - 1.29 linux/drivers/ieee1394/csr.c - 1.9 linux/drivers/ieee1394/highlevel.c - 1.9 linux/include/asm-i386/mpspec.h - 1.12 linux/include/asm-i386/apicdef.h - 1.9 linux/drivers/scsi/scsi_scan.c - 1.32 linux/drivers/atm/iphase.c - 1.15 linux/arch/ia64/ia32/sys_ia32.c - 1.32 linux/drivers/acorn/char/i2c.c - 1.6 linux/arch/arm/kernel/time-acorn.c - 1.4 linux/drivers/scsi/qla1280.h - 1.7 linux/fs/adfs/dir_f.c - 1.9 linux/fs/adfs/dir_fplus.c - 1.8 linux/drivers/scsi/qla1280.c - 1.21 linux/arch/alpha/kernel/irq_srm.c - 1.3 linux/arch/alpha/kernel/irq_i8259.c - 1.5 linux/arch/alpha/kernel/irq_alpha.c - 1.10 linux/net/econet/af_econet.c - 1.15 linux/include/linux/usb.h - 1.48 linux/drivers/usb/serial/usb-serial.c - 1.6 linux/drivers/ide/ide.c - 1.73 linux/drivers/ide/ide-probe.c - 1.43 linux/drivers/ide/ide-floppy.c - 1.38 linux/drivers/ide/ide-disk.c - 1.51 linux/drivers/ide/ide-cd.h - 1.16 linux/drivers/ide/ide-cd.c - 1.51 linux/arch/arm/kernel/arch.c - 1.11 linux/arch/alpha/kernel/irq_pyxis.c - 1.2 linux/net/ipv4/netfilter/ipt_unclean.c - 1.9 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.15 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.9 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.9 linux/net/ipv4/netfilter/ip_nat_core.c - 1.16 linux/net/ipv4/netfilter/ip_fw_compat_masq.c - 1.9 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.16 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.15 linux/include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.7 linux/include/linux/nfs_xdr.h - 1.12 linux/fs/nfs/nfs3proc.c - 1.16 linux/drivers/usb/serial/whiteheat.c - 1.33 linux/drivers/usb/serial/visor.c - 1.43 linux/drivers/net/pppoe.c - 1.23 linux/drivers/s390/block/dasd.c - 1.32 linux/include/asm-arm/arch-sa1100/time.h - 1.6 linux/fs/xfs/xfs_dmapi.c - 1.88 linux/kdb/modules/kdbm_vm.c - 1.25 linux/fs/xfs/linux/xfs_ioctl.c - 1.86 linux/include/linux/profile.h - 1.3 linux/kernel/profile.c - 1.4 linux/kdb/modules/kdbm_pg.c - 1.66 linux/drivers/char/drm/mga_dma.c - 1.9 linux/drivers/usb/storage/usb.h - 1.18 linux/drivers/usb/storage/usb.c - 1.31 linux/drivers/usb/storage/transport.h - 1.12 linux/drivers/usb/storage/transport.c - 1.31 linux/arch/alpha/kernel/sys_titan.c - 1.6 linux/arch/alpha/kernel/sys_wildfire.c - 1.5 linux/fs/jffs/intrep.c - 1.18 linux/drivers/ieee1394/video1394.c - 1.22 linux/drivers/mtd/Config.in - 1.10 linux/drivers/mtd/Makefile - 1.11 linux/drivers/mtd/ftl.c - 1.27 linux/drivers/mtd/mtdblock.c - 1.25 linux/net/ipv4/tcp_minisocks.c - 1.18 linux/drivers/usb/storage/shuttle_usbat.c - 1.13 linux/drivers/usb/storage/sddr09.c - 1.20 linux/drivers/usb/storage/freecom.c - 1.16 linux/drivers/media/video/cpia_usb.c - 1.14 linux/drivers/media/video/cpia_pp.c - 1.7 linux/drivers/media/video/cpia.h - 1.5 linux/drivers/media/video/cpia.c - 1.15 linux/drivers/media/video/bttv-driver.c - 1.23 linux/arch/sh/kernel/setup_cqreek.c - 1.5 linux/arch/sh/kernel/mach_unknown.c - 1.3 linux/arch/sh/kernel/mach_se.c - 1.3 linux/arch/sh/kernel/mach_hp600.c - 1.4 linux/arch/arm/mach-sa1100/Makefile - 1.15 linux/arch/arm/mm/proc-syms.c - 1.4 linux/drivers/block/cciss.c - 1.47 linux/drivers/md/md.c - 1.61 linux/drivers/md/raid0.c - 1.14 linux/drivers/scsi/cpqfc.Readme - 1.8 linux/drivers/scsi/cpqfcTSinit.c - 1.20 linux/drivers/scsi/cpqfcTSstructs.h - 1.12 linux/drivers/usb/storage/initializers.c - 1.3 linux/drivers/media/video/bttvp.h - 1.9 linux/Documentation/SubmittingPatches - 1.3 linux/arch/alpha/lib/ev6-stxncpy.S - 1.4 linux/arch/i386/kernel/dmi_scan.c - 1.22 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.4 linux/arch/s390x/kernel/linux32.c - 1.17 linux/drivers/s390/block/xpram.c - 1.28 linux/include/asm-cris/uaccess.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.19 linux/net/wanrouter/af_wanpipe.c - 1.10 linux/arch/sh/kernel/setup_hd64465.c - 1.3 linux/arch/sh/kernel/setup_ec3104.c - 1.4 linux/arch/sh/kernel/setup_dc.c - 1.5 linux/arch/sh/kernel/mach_ec3104.c - 1.2 linux/arch/sh/kernel/mach_dmida.c - 1.2 linux/arch/sh/kernel/mach_dc.c - 1.5 linux/arch/sh/kernel/mach_cat68701.c - 1.2 linux/include/asm-arm/proc-armv/pgalloc.h - 1.5 linux/arch/cris/drivers/examples/kiobuftest.c - 1.3 linux/include/net/bluetooth/bluetooth.h - 1.7 linux/include/net/bluetooth/hci.h - 1.6 linux/include/net/bluetooth/hci_core.h - 1.6 linux/drivers/bluetooth/hci_usb.c - 1.14 linux/drivers/bluetooth/Makefile - 1.7 linux/drivers/bluetooth/Config.in - 1.6 linux/net/bluetooth/Makefile - 1.6 linux/net/bluetooth/af_bluetooth.c - 1.8 linux/net/bluetooth/hci_core.c - 1.9 linux/net/bluetooth/hci_sock.c - 1.8 linux/net/bluetooth/lib.c - 1.6 linux/net/bluetooth/syms.c - 1.4 linux/drivers/mtd/nftlcore.c - 1.27 linux/drivers/mtd/bootldr.c - 1.3 linux/drivers/mtd/mtdblock_ro.c - 1.15 linux/drivers/mtd/maps/sa1100-flash.c - 1.3 linux/drivers/mtd/maps/iq80310.c - 1.3 linux/drivers/mtd/maps/dc21285.c - 1.3 linux/drivers/mtd/maps/Makefile - 1.5 linux/drivers/mtd/maps/Config.in - 1.8 linux/arch/sh/kernel/setup_sh2000.c - 1.2 linux/arch/sh/stboards/mach.c - 1.2 linux/arch/sh/kernel/mach_bigsur.c - 1.2 linux/drivers/message/fusion/mptscsih.h - 1.7 linux/drivers/message/fusion/mptscsih.c - 1.11 linux/drivers/message/fusion/mptlan.h - 1.5 linux/drivers/message/fusion/mptlan.c - 1.7 linux/drivers/message/fusion/mptctl.c - 1.10 linux/drivers/message/fusion/mptbase.h - 1.7 linux/drivers/message/fusion/mptbase.c - 1.7 linux/drivers/message/fusion/lsi/mpi_targ.h - 1.5 linux/drivers/message/fusion/lsi/mpi_cnfg.h - 1.5 linux/drivers/message/fusion/lsi/mpi.h - 1.5 linux/drivers/message/fusion/Config.in - 1.4 linux/drivers/message/fusion/linux_compat.h - 1.5 linux/drivers/ieee1394/sbp2.c - 1.14 linux/drivers/ieee1394/sbp2.h - 1.10 linux/drivers/usb/storage/jumpshot.c - 1.9 linux/drivers/usb/storage/isd200.c - 1.10 linux/drivers/usb/storage/datafab.c - 1.9 linux/drivers/char/drm/drm_ioctl.h - 1.3 linux/arch/arm/mach-sa1100/sa1111.c - 1.11 linux/arch/arm/mach-sa1100/neponset.c - 1.13 linux/arch/arm/mach-integrator/cpu.c - 1.7 linux/arch/arm/mach-sa1100/assabet.c - 1.14 linux/arch/arm/mach-sa1100/generic.c - 1.11 linux/drivers/scsi/dpti.h - 1.4 linux/drivers/scsi/dpt_i2o.c - 1.15 linux/drivers/bluetooth/hci_vhci.c - 1.7 linux/arch/sh/kernel/mach_adx.c - 1.2 linux/arch/sh/kernel/mach_7751se.c - 1.2 linux/fs/jffs2/background.c - 1.14 linux/arch/i386/kernel/nmi.c - 1.9 linux/include/asm-arm/tlb.h - 1.5 linux/drivers/mtd/maps/integrator-flash.c - 1.2 linux/include/asm-i386/smpboot.h - 1.3 linux/drivers/mtd/afs.c - 1.2 linux/drivers/pcmcia/sa1100_graphicsclient.c - 1.3 linux/drivers/pcmcia/sa1100_generic.c - 1.11 linux/drivers/pcmcia/sa1100_freebird.c - 1.3 linux/drivers/pcmcia/sa1100_flexanet.c - 1.3 linux/drivers/pcmcia/sa1100_cerf.c - 1.4 linux/drivers/pcmcia/sa1100_assabet.c - 1.5 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.4 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.4 linux/drivers/pcmcia/sa1100_h3600.c - 1.3 linux/drivers/pcmcia/sa1100_jornada720.c - 1.4 linux/drivers/pcmcia/sa1100_neponset.c - 1.6 linux/drivers/pcmcia/sa1100_pangolin.c - 1.3 linux/drivers/pcmcia/sa1100_pfs168.c - 1.4 linux/drivers/pcmcia/sa1100_simpad.c - 1.4 linux/drivers/pcmcia/sa1100_stork.c - 1.4 linux/drivers/pcmcia/sa1100_xp860.c - 1.4 linux/drivers/pcmcia/sa1100_yopy.c - 1.3 linux/drivers/message/i2o/i2o_scsi.h - 1.4 linux/drivers/message/i2o/i2o_scsi.c - 1.9 linux/drivers/message/i2o/i2o_block.c - 1.25 linux/net/ipv6/netfilter/ip6t_LOG.c - 1.4 linux/drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.4 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.8 linux/fs/ext3/ialloc.c - 1.16 linux/fs/intermezzo/ext_attr.c - 1.4 linux/fs/intermezzo/file.c - 1.5 linux/fs/intermezzo/inode.c - 1.5 linux/fs/intermezzo/journal.c - 1.5 linux/fs/intermezzo/journal_ext2.c - 1.6 linux/fs/intermezzo/journal_ext3.c - 1.6 linux/fs/intermezzo/journal_obdfs.c - 1.6 linux/fs/intermezzo/journal_reiserfs.c - 1.6 linux/fs/intermezzo/journal_xfs.c - 1.8 linux/fs/intermezzo/kml_reint.c - 1.5 linux/fs/intermezzo/methods.c - 1.6 linux/fs/intermezzo/presto.c - 1.9 linux/fs/intermezzo/psdev.c - 1.8 linux/fs/intermezzo/super.c - 1.7 linux/fs/intermezzo/sysctl.c - 1.6 linux/fs/intermezzo/upcall.c - 1.5 linux/fs/intermezzo/vfs.c - 1.10 linux/include/linux/intermezzo_psdev.h - 1.3 linux/include/linux/intermezzo_fs.h - 1.5 linux/include/linux/fsfilter.h - 1.2 linux/fs/intermezzo/cache.c - 1.6 linux/fs/intermezzo/Makefile - 1.3 linux/fs/intermezzo/dir.c - 1.8 linux/fs/intermezzo/dcache.c - 1.6 linux/fs/bio.c - 1.21 linux/drivers/block/block_ioctl.c - 1.11 linux/include/linux/device.h - 1.20 linux/arch/arm/mm/minicache.c - 1.7 linux/include/asm-arm/hardware/sa1111.h - 1.7 linux/arch/arm/mach-iop310/iop310-pci.c - 1.6 linux/arch/arm/mach-iop310/iq80310-time.c - 1.6 linux/drivers/ieee1394/dv1394.c - 1.9 linux/arch/i386/Config.help - 1.17 linux/net/bluetooth/Config.help - 1.4 linux/fs/Config.help - 1.22 linux/drivers/bluetooth/Config.help - 1.5 linux/drivers/char/Config.help - 1.13 linux/drivers/message/fusion/Config.help - 1.2 linux/drivers/mtd/Config.help - 1.2 linux/drivers/mtd/maps/Config.help - 1.3 linux/drivers/base/core.c - 1.17 linux/sound/pci/ymfpci/ymfpci_main.c - 1.8 linux/sound/pci/ens1370.c - 1.10 linux/sound/pci/emu10k1/emufx.c - 1.8 linux/sound/pci/Config.in - 1.8 linux/sound/oss/dmabuf.c - 1.3 linux/arch/x86_64/boot/Makefile - 1.7 linux/arch/x86_64/boot/compressed/Makefile - 1.3 linux/arch/x86_64/boot/compressed/misc.c - 1.2 linux/arch/x86_64/boot/compressed/miscsetup.h - 1.2 linux/arch/x86_64/boot/video.S - 1.4 linux/arch/x86_64/ia32/Makefile - 1.7 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.5 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.9 linux/arch/x86_64/ia32/ia32_signal.c - 1.5 linux/arch/x86_64/ia32/ia32entry.S - 1.4 linux/arch/x86_64/ia32/ptrace32.c - 1.3 linux/arch/x86_64/ia32/socket32.c - 1.2 linux/arch/x86_64/ia32/sys_ia32.c - 1.8 linux/arch/x86_64/kernel/Makefile - 1.7 linux/arch/x86_64/kernel/apic.c - 1.4 linux/arch/x86_64/kernel/bluesmoke.c - 1.5 linux/arch/x86_64/kernel/cpuid.c - 1.4 linux/arch/x86_64/kernel/early_printk.c - 1.5 linux/arch/x86_64/kernel/entry.S - 1.6 linux/arch/x86_64/kernel/head.S - 1.5 linux/arch/x86_64/kernel/head64.c - 1.4 linux/arch/x86_64/kernel/i8259.c - 1.4 linux/arch/x86_64/kernel/init_task.c - 1.3 linux/arch/x86_64/kernel/io_apic.c - 1.3 linux/arch/x86_64/kernel/ioport.c - 1.3 linux/arch/x86_64/kernel/irq.c - 1.5 linux/arch/x86_64/kernel/ldt.c - 1.5 linux/arch/x86_64/kernel/mpparse.c - 1.4 linux/arch/x86_64/kernel/msr.c - 1.4 linux/arch/x86_64/kernel/mtrr.c - 1.7 linux/arch/x86_64/kernel/nmi.c - 1.3 linux/arch/x86_64/kernel/pci-dma.c - 1.3 linux/arch/x86_64/kernel/process.c - 1.8 linux/arch/x86_64/kernel/ptrace.c - 1.4 linux/arch/x86_64/kernel/semaphore.c - 1.3 linux/arch/x86_64/kernel/setup.c - 1.4 linux/arch/x86_64/kernel/setup64.c - 1.5 linux/arch/x86_64/kernel/signal.c - 1.7 linux/arch/x86_64/kernel/smp.c - 1.8 linux/arch/x86_64/kernel/smpboot.c - 1.6 linux/arch/x86_64/kernel/time.c - 1.5 linux/arch/x86_64/kernel/trampoline.S - 1.3 linux/arch/x86_64/kernel/traps.c - 1.7 linux/arch/x86_64/kernel/vsyscall.c - 1.6 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.8 linux/arch/x86_64/lib/Makefile - 1.7 linux/arch/x86_64/lib/usercopy.c - 1.3 linux/sound/isa/wavefront/wavefront_synth.c - 1.6 linux/sound/isa/sb/emu8000.c - 1.7 linux/sound/isa/opl3sa2.c - 1.10 linux/sound/isa/es18xx.c - 1.8 linux/sound/core/timer.c - 1.7 linux/sound/core/sound_oss.c - 1.5 linux/sound/core/sound.c - 1.9 linux/sound/core/seq/seq_memory.c - 1.6 linux/sound/core/seq/seq_lock.h - 1.3 linux/sound/core/seq/seq_lock.c - 1.4 linux/sound/core/seq/seq_fifo.c - 1.4 linux/sound/core/seq/seq_clientmgr.c - 1.9 linux/sound/core/seq/seq.c - 1.3 linux/sound/core/seq/oss/seq_oss_writeq.c - 1.3 linux/sound/core/seq/oss/seq_oss_synth.c - 1.5 linux/sound/core/seq/oss/seq_oss_readq.c - 1.4 linux/sound/core/rawmidi.c - 1.9 linux/sound/core/pcm_native.c - 1.9 linux/sound/core/pcm_lib.c - 1.8 linux/sound/core/oss/pcm_oss.c - 1.10 linux/sound/core/oss/mixer_oss.c - 1.5 linux/sound/core/memory.c - 1.11 linux/sound/core/init.c - 1.6 linux/sound/core/info_oss.c - 1.5 linux/sound/core/control.c - 1.7 linux/include/asm-x86_64/semaphore.h - 1.3 linux/include/asm-x86_64/segment.h - 1.3 linux/include/asm-x86_64/rwsem.h - 1.5 linux/include/asm-x86_64/ptrace.h - 1.4 linux/include/asm-x86_64/processor.h - 1.7 linux/include/asm-x86_64/pgtable.h - 1.8 linux/include/asm-x86_64/pda.h - 1.6 linux/include/asm-x86_64/pci.h - 1.3 linux/include/asm-x86_64/param.h - 1.2 linux/include/asm-x86_64/page.h - 1.5 linux/include/asm-x86_64/mpspec.h - 1.3 linux/include/asm-x86_64/mmu_context.h - 1.6 linux/include/asm-x86_64/mman.h - 1.3 linux/include/asm-x86_64/ldt.h - 1.3 linux/include/asm-x86_64/kmap_types.h - 1.4 linux/include/asm-x86_64/ipc.h - 1.4 linux/include/asm-x86_64/io_apic.h - 1.3 linux/include/asm-x86_64/io.h - 1.4 linux/include/asm-x86_64/ide.h - 1.7 linux/include/asm-x86_64/ia32_unistd.h - 1.3 linux/include/asm-x86_64/hardirq.h - 1.2 linux/include/asm-x86_64/elf.h - 1.3 linux/include/asm-x86_64/e820.h - 1.2 linux/include/asm-x86_64/desc.h - 1.4 linux/include/asm-x86_64/cpufeature.h - 1.3 linux/include/asm-x86_64/calling.h - 1.3 linux/include/asm-x86_64/bitops.h - 1.5 linux/include/asm-x86_64/apic.h - 1.4 linux/include/sound/version.h - 1.11 linux/include/sound/info.h - 1.4 linux/include/asm-x86_64/system.h - 1.6 linux/include/sound/core.h - 1.11 linux/include/sound/asound.h - 1.10 linux/include/asm-x86_64/signal.h - 1.3 linux/include/asm-x86_64/smp.h - 1.3 linux/include/asm-x86_64/socket.h - 1.2 linux/include/asm-x86_64/softirq.h - 1.3 linux/include/asm-x86_64/spinlock.h - 1.4 linux/include/asm-x86_64/xor.h - 1.4 linux/include/asm-x86_64/vsyscall.h - 1.3 linux/include/asm-x86_64/user.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.7 linux/include/asm-x86_64/types.h - 1.4 linux/include/asm-x86_64/timex.h - 1.5 linux/include/asm-x86_64/thread_info.h - 1.4 linux/arch/ppc64/kernel/sys_ppc32.c - 1.10 linux/fs/jfs/jfs_dtree.c - 1.10 linux/include/asm-arm/glue.h - 1.5 linux/arch/arm/mm/tlb-v4wb.S - 1.4 linux/fs/jfs/jfs_mount.c - 1.11 linux/arch/arm/mm/tlb-v4.S - 1.5 linux/arch/arm/mm/tlb-v3.S - 1.4 linux/sound/pci/Config.help - 1.6 linux/drivers/pcmcia/sa1100_system3.c - 1.3 linux/drivers/pcmcia/sa1100_shannon.c - 1.2 linux/drivers/pcmcia/sa1100_badge4.c - 1.4 linux/sound/core/ioctl32/pcm32.c - 1.5 linux/sound/core/ioctl32/ioctl32.h - 1.4 linux/sound/core/ioctl32/ioctl32.c - 1.6 linux/kernel/futex.c - 1.12 linux/mm/msync.c - 1.7 linux/drivers/media/video/video-buf.h - 1.3 linux/drivers/media/video/video-buf.c - 1.4 linux/drivers/media/video/bttv-risc.c - 1.2 linux/drivers/ieee1394/eth1394.c - 1.3 linux/drivers/usb/core/hub.c - 1.14 linux/drivers/usb/core/inode.c - 1.10 linux/drivers/usb/core/usb.c - 1.20 linux/drivers/usb/host/ehci-hcd.c - 1.11 linux/drivers/ieee1394/cmp.c - 1.3 linux/drivers/usb/input/wacom.c - 1.6 linux/drivers/usb/media/Makefile - 1.5 linux/drivers/ieee1394/eth1394.h - 1.3 linux/drivers/video/clps711xfb.c - 1.7 linux/drivers/usb/net/usbnet.c - 1.12 linux/drivers/usb/media/vicam.c - 1.5 linux/drivers/usb/media/vicam.h - 1.2 linux/drivers/usb/media/vicamurbs.h - 1.3 linux/include/asm-x86_64/cacheflush.h - 1.3 linux/include/asm-x86_64/percpu.h - 1.4 linux/include/asm-arm/proc-armv/tlbflush.h - 1.2 linux/drivers/pcmcia/sa1100_trizeps.c - 1.2 linux/arch/x86_64/lib/thunk.S - 1.2 linux/Documentation/DocBook/scsidrivers.tmpl - 1.2 linux/drivers/char/synclinkmp.c - 1.4 linux/drivers/char/pcmcia/synclink_cs.c - 1.5 linux/drivers/block/umem.c - 1.13 linux/drivers/bluetooth/bluecard_cs.c - 1.4 linux/drivers/usb/host/uhci-hcd.c - 1.10 linux/fs/fs-writeback.c - 1.9 linux/net/bluetooth/sco.c - 1.4 linux/net/bluetooth/l2cap.c - 1.4 linux/net/bluetooth/hci_event.c - 1.3 linux/net/bluetooth/hci_conn.c - 1.3 linux/drivers/bluetooth/dtl1_cs.c - 1.4 linux/drivers/bluetooth/hci_h4.c - 1.4 linux/drivers/bluetooth/hci_ldisc.c - 1.4 linux/mm/page-writeback.c - 1.14 linux/include/linux/buffer_head.h - 1.13 linux/drivers/usb/storage/sddr55.c - 1.4 linux/include/linux/writeback.h - 1.10 linux/drivers/usb/storage/raw_bulk.h - 1.2 linux/include/linux/suspend.h - 1.6 linux/drivers/usb/host/hc_sl811.c - 1.4 linux/drivers/acorn/scsi/scsi.h - 1.2 linux/drivers/usb/storage/raw_bulk.c - 1.5 linux/drivers/usb/core/urb.c - 1.7 linux/drivers/usb/core/message.c - 1.9 linux/drivers/usb/host/ohci-sa1111.c - 1.6 linux/drivers/usb/core/hcd-pci.c - 1.5 linux/drivers/usb/host/ohci-pci.c - 1.3 linux/drivers/s390/block/dasd_genhd.c - 1.11 linux/arch/x86_64/pci/x86-64.c - 1.2 linux/arch/x86_64/lib/csum-copy.S - 1.2 linux/arch/x86_64/lib/copy_user.S - 1.2 linux/arch/x86_64/lib/copy_page.S - 1.2 linux/arch/x86_64/lib/clear_page.S - 1.2 linux/arch/x86_64/pci/pci.h - 1.2 linux/arch/x86_64/lib/memcpy.S - 1.2 linux/arch/x86_64/lib/memset.S - 1.3 linux/arch/x86_64/pci/Makefile - 1.2 linux/arch/x86_64/pci/fixup.c - 1.2 linux/arch/x86_64/pci/common.c - 1.2 linux/include/asm-x86_64/agp.h - 1.2 linux/arch/x86_64/ia32/ipc32.c - 1.2 linux/arch/x86_64/kernel/asm-offsets.c - 1.2 linux/drivers/message/fusion/mptctl.h - 1.2 linux/fs/direct-io.c - 1.10 linux/drivers/usb/serial/io_ti.c - 1.4 linux/drivers/serial/core.c - 1.4 linux/drivers/serial/Makefile - 1.3 linux/drivers/serial/Config.in - 1.4 linux/drivers/serial/Config.help - 1.3 linux/drivers/serial/8250.c - 1.8 linux/drivers/bluetooth/bt3c_cs.c - 1.3 linux/drivers/char/drm/drm_os_linux.h - 1.4 linux/fs/aio.c - 1.7 linux/net/sctp/protocol.c - 1.6 linux/net/sctp/socket.c - 1.5 linux/fs/xfs/linux/xfs_aops.c - 1.15 linux/arch/i386/mm/discontig.c - 1.5 linux/include/asm-um/thread_info.h - 1.2 linux/include/asm-um/smp.h - 1.2 linux/drivers/ide/legacy/hd.c - 1.8 linux/arch/um/Makefile - 1.5 linux/arch/um/Makefile-i386 - 1.2 linux/arch/um/config.in - 1.3 linux/arch/um/drivers/chan_user.c - 1.2 linux/arch/um/drivers/harddog_kern.c - 1.2 linux/arch/um/drivers/hostaudio_kern.c - 1.2 linux/arch/um/drivers/line.c - 1.3 linux/arch/um/drivers/mconsole_kern.c - 1.3 linux/arch/um/drivers/mconsole_user.c - 1.2 linux/arch/um/drivers/mmapper_kern.c - 1.2 linux/arch/um/drivers/net_kern.c - 1.3 linux/arch/um/drivers/port_kern.c - 1.3 linux/arch/um/drivers/ssl.c - 1.2 linux/arch/um/drivers/stdio_console.c - 1.2 linux/arch/um/drivers/ubd_kern.c - 1.5 linux/arch/um/drivers/ubd_user.c - 1.2 linux/arch/um/drivers/xterm.c - 1.2 linux/arch/um/include/2_5compat.h - 1.3 linux/arch/um/include/irq_user.h - 1.2 linux/arch/um/include/kern_util.h - 1.2 linux/arch/um/include/line.h - 1.3 linux/arch/um/include/mconsole.h - 1.2 linux/arch/um/include/sigio.h - 1.2 linux/arch/um/include/user_util.h - 1.4 linux/arch/um/kernel/Makefile - 1.5 linux/arch/um/kernel/exec_kern.c - 1.2 linux/arch/um/kernel/exitcode.c - 1.2 linux/arch/um/kernel/frame.c - 1.2 linux/arch/um/kernel/helper.c - 1.2 linux/arch/um/kernel/initrd_kern.c - 1.2 linux/arch/um/kernel/irq.c - 1.2 linux/arch/um/kernel/irq_user.c - 1.3 linux/arch/um/kernel/ksyms.c - 1.2 linux/arch/um/kernel/mem.c - 1.4 linux/arch/um/kernel/mem_user.c - 1.3 linux/arch/um/kernel/process.c - 1.3 linux/arch/um/kernel/process_kern.c - 1.4 linux/arch/um/kernel/sigio_kern.c - 1.2 linux/arch/um/kernel/sigio_user.c - 1.2 linux/arch/um/kernel/signal_user.c - 1.2 linux/arch/um/kernel/smp.c - 1.2 linux/arch/um/kernel/syscall_kern.c - 1.2 linux/arch/um/kernel/syscall_user.c - 1.2 linux/arch/um/kernel/time.c - 1.3 linux/arch/um/kernel/time_kern.c - 1.3 linux/arch/um/kernel/trap_kern.c - 1.2 linux/arch/um/kernel/trap_user.c - 1.3 linux/arch/um/kernel/tty_log.c - 1.2 linux/arch/um/kernel/um_arch.c - 1.3 linux/arch/um/kernel/umid.c - 1.2 linux/arch/um/kernel/user_util.c - 1.2 linux/arch/um/main.c - 1.2 linux/arch/um/ptproxy/proxy.c - 1.2 linux/arch/um/sys-i386/bugs.c - 1.2 linux/arch/um/sys-i386/ptrace_user.c - 1.2 linux/arch/um/sys-i386/util/Makefile - 1.2 linux/arch/um/sys-ppc/miscthings.c - 1.2 linux/arch/um/util/Makefile - 1.3 linux/include/asm-um/cache.h - 1.2 linux/arch/x86_64/vmlinux.lds.S - 1.2 linux/arch/arm/vmlinux.lds.S - 1.2 linux/arch/i386/mach-generic/do_timer.h - 1.2 linux/arch/i386/mach-visws/do_timer.h - 1.2 linux/include/linux/vcache.h - 1.2 linux/mm/vcache.c - 1.2 linux/net/llc/af_llc.c - 1.3 linux/arch/um/uml.lds.S - 1.2 linux/sound/usb/usbquirks.h - 1.2 linux/sound/usb/usbmixer.c - 1.2 linux/sound/usb/usbaudio.c - 1.2 linux/drivers/bluetooth/hci_bcsp.c - 1.2 linux/net/llc/llc_proc.c - 1.3 linux/drivers/scsi/aacraid/linit.c - 1.2 linux/drivers/scsi/aacraid/Makefile - 1.3 linux/net/bluetooth/bnep/netdev.c - 1.2 linux/net/bluetooth/rfcomm/tty.c - 1.3 linux/net/bluetooth/rfcomm/sock.c - 1.3 linux/net/bluetooth/rfcomm/core.c - 1.3 linux/net/bluetooth/rfcomm/Makefile - 1.2 linux/net/bluetooth/rfcomm/Config.in - 1.2 linux/net/bluetooth/rfcomm/Config.help - 1.2 linux/net/bluetooth/bnep/sock.c - 1.2 linux/net/bluetooth/bnep/core.c - 1.2 linux/net/bluetooth/bnep/Config.help - 1.2 linux/net/bluetooth/bnep/Makefile - 1.2 linux/net/bluetooth/bnep/Config.in - 1.2 linux/fs/cifs/asn1.c - 1.2 linux/fs/cifs/cifs_debug.c - 1.2 linux/fs/cifs/cifs_debug.h - 1.2 linux/fs/cifs/cifssmb.c - 1.2 linux/fs/cifs/connect.c - 1.2 linux/fs/cifs/file.c - 1.2 linux/fs/cifs/inode.c - 1.2 linux/arch/alpha/kernel/systbls.S - 1.2 linux/arch/i386/kernel/timers/timer_tsc.c - 1.2 linux/fs/cifs/nterr.c - 1.2 linux/arch/um/include/time_user.h - 1.2 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Oct 16 13:38:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 13:39:01 -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 g9GKcttG021287 for ; Wed, 16 Oct 2002 13:38:56 -0700 Received: from erbenson.alaska.net (115-pm14.nwc.alaska.net [209.112.141.115]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GKcsVx096096 for ; Wed, 16 Oct 2002 12:38:54 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 50EC43A0B for ; Wed, 16 Oct 2002 12:38:53 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 750AC4104E2; Wed, 16 Oct 2002 12:38:53 -0800 (AKDT) Date: Wed, 16 Oct 2002 12:38:53 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016203853.GH27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016085626.GB27982@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SdvjNjn6lL3tIsv0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1021 X-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 --SdvjNjn6lL3tIsv0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 05:50:47AM -0400, TJ Easter wrote: > Anyone know if there are plans to impliment the immutable/append-only > options? a couple monthes ago Steve said it looked like it would be pretty easy to do, and without breaking backward compatibilty (since older implementations would simply ignore the bits). he just doesn't really have time, someone with a little experience in the XFS code could probably do it though. immutable, append-only, and the S (sync) bits would be the useful ones. > Regards, > -tje- >=20 > On Wed, 16 Oct 2002, Ethan Benson wrote: >=20 > > On Wed, Oct 16, 2002 at 10:46:59AM +0200, Fabien Combernous wrote: > > > Lo, > > > > > > Actualy i'm looking for documents about journalised file system, in > > > order to be able to compare them self. I need accurate information if= i > > > want to make a good study. > > > > > > Thoses informations have to permit me to get answer about table like = this : > > > > > > Features \ fs | xfs | ext3 | jfs | reiserfs | > > > ------------------------------------------------- > > > chattr | ? | Y | ? | ? | > > > > if you mean immutable/append only xfs doesn't have that, but its been > > found it would be easy to add. reiserfs already did add it. > > > > -- > > Ethan Benson > > http://www.alaska.net/~erbenson/ > > --=20 Ethan Benson http://www.alaska.net/~erbenson/ --SdvjNjn6lL3tIsv0 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 iEYEARECAAYFAj2tzl0ACgkQJKx7GixEevyKjwCfa1ce1YiL9HuwcWAhfzx+ia69 490AoIqasazCeM0VQ7ePpkjbz+o2aAEk =7dd5 -----END PGP SIGNATURE----- --SdvjNjn6lL3tIsv0-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:26:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:27:03 -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 g9GLQwtG026798 for ; Wed, 16 Oct 2002 14:26:58 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 9EB3214F77 for ; Wed, 16 Oct 2002 23:26:52 +0200 (MEST) Date: Wed, 16 Oct 2002 23:26:52 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016232652.A14553@wotan.suse.de> References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016203853.GH27982@plato.local.lan> User-Agent: Mutt/1.3.22.1i X-archive-position: 1022 X-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 16, 2002 at 12:38:53PM -0800, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:50:47AM -0400, TJ Easter wrote: > > Anyone know if there are plans to impliment the immutable/append-only > > options? > > a couple monthes ago Steve said it looked like it would be pretty easy > to do, and without breaking backward compatibilty (since older > implementations would simply ignore the bits). he just doesn't really > have time, someone with a little experience in the XFS code could > probably do it though. > > immutable, append-only, and the S (sync) bits would be the useful ones. 'D' for directories is quite useful too, because some mail servers assume that everybody has synchronous rename() like traditional BSD FFS. 'd' (don't dump) should be also simple and useful. and of course 'u' if it was implemented (probably a bit more work) would clear a major FAQ item on this list. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:34:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:34:46 -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 g9GLYctG027877 for ; Wed, 16 Oct 2002 14:34:39 -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 OAA03861 for ; Wed, 16 Oct 2002 14:34:34 -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 HAA16585; Thu, 17 Oct 2002 07:33:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA03004; Thu, 17 Oct 2002 07:33:16 +1000 (EST) Date: Thu, 17 Oct 2002 07:33:16 +1000 From: Nathan Scott To: Eric Sandeen Cc: ?eref Tufan ?en , linux-xfs@oss.sgi.com Subject: Re: XFS 1.2Pre and nfs problem Message-ID: <20021017073316.A302869@wobbly.melbourne.sgi.com> References: <20021011124432.253ca55a.tufan@itu.edu.tr> <1034352726.1162.7.camel@rose.americas.sgi.com> <20021012140349.3c28bcc9.tufan@itu.edu.tr> <20021016115430.724d3b18.tufan@itu.edu.tr> <1034779623.15573.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1034779623.15573.0.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Oct 16, 2002 at 09:46:58AM -0500 X-archive-position: 1023 X-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 Wed, Oct 16, 2002 at 09:46:58AM -0500, Eric Sandeen wrote: > Did this generate any errors in your system logs? > 990 (EFSCORRUPTED) can be generated by xfs_repair itself (via libxfs). Its not supposed to happen, but it can. :( Running ltrace on xfs_repair would help to find the offending routine in libxfs. > > > > Phase 7 - verify and correct link counts... > > > > fatal error -- couldn't map inode 68355923, err = 990 > > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:37:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:37:59 -0700 (PDT) Received: from skreak.org (W00t@ddsl-66-161-218-122.fuse.net [66.161.218.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GLbutG028591 for ; Wed, 16 Oct 2002 14:37:56 -0700 Received: (qmail 6070 invoked from network); 16 Oct 2002 21:41:20 -0000 Received: from localhost (127.0.0.1) by skreak.org with SMTP; 16 Oct 2002 21:41:20 -0000 Date: Wed, 16 Oct 2002 17:41:20 -0400 (EDT) From: TJ Easter To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems In-Reply-To: <20021016203853.GH27982@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1024 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tje@skreak.org Precedence: bulk X-list: linux-xfs I'm far from an expert level C programmer, but I will examine the code and see if I am able to come up with anything and submit patches. Regards, -tj- On Wed, 16 Oct 2002, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:50:47AM -0400, TJ Easter wrote: > > Anyone know if there are plans to impliment the immutable/append-only > > options? > > a couple monthes ago Steve said it looked like it would be pretty easy > to do, and without breaking backward compatibilty (since older > implementations would simply ignore the bits). he just doesn't really > have time, someone with a little experience in the XFS code could > probably do it though. > > immutable, append-only, and the S (sync) bits would be the useful ones. > > > Regards, > > -tje- > > > > On Wed, 16 Oct 2002, Ethan Benson wrote: > > > > > On Wed, Oct 16, 2002 at 10:46:59AM +0200, Fabien Combernous wrote: > > > > Lo, > > > > > > > > Actualy i'm looking for documents about journalised file system, in > > > > order to be able to compare them self. I need accurate information if i > > > > want to make a good study. > > > > > > > > Thoses informations have to permit me to get answer about table like this : > > > > > > > > Features \ fs | xfs | ext3 | jfs | reiserfs | > > > > ------------------------------------------------- > > > > chattr | ? | Y | ? | ? | > > > > > > if you mean immutable/append only xfs doesn't have that, but its been > > > found it would be easy to add. reiserfs already did add it. > > > > > > -- > > > Ethan Benson > > > http://www.alaska.net/~erbenson/ > > > > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:48:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:48:06 -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 g9GLm3tG029844 for ; Wed, 16 Oct 2002 14:48:03 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GLm0Vx053914 for ; Wed, 16 Oct 2002 13:48:00 -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 16CBC3A0B for ; Wed, 16 Oct 2002 13:47:59 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 47CE04104E2; Wed, 16 Oct 2002 13:47:59 -0800 (AKDT) Date: Wed, 16 Oct 2002 13:47:59 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016214759.GI27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016203853.GH27982@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cVp8NMj01v+Em8Se" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1025 X-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 --cVp8NMj01v+Em8Se Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 05:41:20PM -0400, TJ Easter wrote: > I'm far from an expert level C programmer, but I will examine the code and > see if I am able to come up with anything and submit patches. im fine with C, its just finding my way around the XFS source is quite a challenge, unless your familier with its internals its quite easy to get lost. i believe the right place for them is the di_flags, defined in xfs_dinode.h (at the bottom). basically as i understand it you need check for these bits in the xfs diflags and fill the VFS inode flags, the VFS defines bits for immutable/append-only in a generic way, all XFS needs to do is inform the VFS that an inode is immutable, it will handle all the enforcment.=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --cVp8NMj01v+Em8Se 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 iEYEARECAAYFAj2t3o8ACgkQJKx7GixEevzgggCffWsu84efCmFFuXLJwfjYvevV MbYAnR1plcXn1s7uPdj7BiU3wpuTT22H =xHB2 -----END PGP SIGNATURE----- --cVp8NMj01v+Em8Se-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:50:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:50:48 -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 g9GLojtG030512 for ; Wed, 16 Oct 2002 14:50:45 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GLoiVx058202 for ; Wed, 16 Oct 2002 13:50:44 -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 1208D3A0B for ; Wed, 16 Oct 2002 13:50:43 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 697F04104E2; Wed, 16 Oct 2002 13:50:43 -0800 (AKDT) Date: Wed, 16 Oct 2002 13:50:43 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016215043.GJ27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> <20021016232652.A14553@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xssso5lpTBgMxDfe" Content-Disposition: inline In-Reply-To: <20021016232652.A14553@wotan.suse.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1026 X-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 --Xssso5lpTBgMxDfe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 11:26:52PM +0200, Andi Kleen wrote: > On Wed, Oct 16, 2002 at 12:38:53PM -0800, Ethan Benson wrote: > > On Wed, Oct 16, 2002 at 05:50:47AM -0400, TJ Easter wrote: > > > Anyone know if there are plans to impliment the immutable/append-only > > > options? > >=20 > > a couple monthes ago Steve said it looked like it would be pretty easy > > to do, and without breaking backward compatibilty (since older > > implementations would simply ignore the bits). he just doesn't really > > have time, someone with a little experience in the XFS code could > > probably do it though. > >=20 > > immutable, append-only, and the S (sync) bits would be the useful ones. >=20 > 'D' for directories is quite useful too, because some mail servers > assume that everybody has synchronous rename() like traditional BSD FFS. your thinking S which can be applied to both files and directories.=20=20 there is no chattr +D at least in my version of it. > 'd' (don't dump) should be also simple and useful. xfs already honors an extended attribute for files only, the maintainers believe that honoring such a thing for directories is evil. > and of course 'u' if it was implemented (probably a bit more work)=20 > would clear a major FAQ item on this list. not even ext2 supports u. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Xssso5lpTBgMxDfe 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 iEYEARECAAYFAj2t3zMACgkQJKx7GixEevx15wCfcatmi4JL+bqZuV6B/gUIlsKo /jcAniByAroHdZ8TteLhH6LBqzOVqPto =QTlI -----END PGP SIGNATURE----- --Xssso5lpTBgMxDfe-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:52:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:52: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 g9GLqVtG031139 for ; Wed, 16 Oct 2002 14:52:31 -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 QAA08458; Wed, 16 Oct 2002 16:52:26 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA76375; Wed, 16 Oct 2002 16:52:25 -0500 (CDT) Subject: Re: to compare journalised file systems From: Stephen Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021016214759.GI27982@plato.local.lan> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 16:48:22 -0500 Message-Id: <1034804904.1461.73.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1027 X-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-16 at 16:47, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:41:20PM -0400, TJ Easter wrote: > > I'm far from an expert level C programmer, but I will examine the code and > > see if I am able to come up with anything and submit patches. > > im fine with C, its just finding my way around the XFS source is quite > a challenge, unless your familier with its internals its quite easy to > get lost. > > i believe the right place for them is the di_flags, defined in > xfs_dinode.h (at the bottom). > > basically as i understand it you need check for these bits in the xfs > diflags and fill the VFS inode flags, the VFS defines bits for > immutable/append-only in a generic way, all XFS needs to do is > inform the VFS that an inode is immutable, it will handle all the > enforcment. And setting them is a slightly different matter, but basically this chunk of code in xfs_setattr would need extending with different flags, and we would need to map the setting of the bits down into a VOP_SETATTR in xfs with the AT_XFLAGS set: if (mask & AT_XFLAGS) { ip->i_d.di_flags = 0; if (vap->va_xflags & XFS_XFLAG_REALTIME) { ip->i_d.di_flags |= XFS_DIFLAG_REALTIME; /* This is replicated in the io core for * CXFS use */ ip->i_iocore.io_flags |= XFS_IOCORE_RT; } /* can't set PREALLOC this way, just ignore it */ } Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 14:57:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 14:57: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 g9GLvItG031975 for ; Wed, 16 Oct 2002 14:57:19 -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 QAA14679; Wed, 16 Oct 2002 16:57:13 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA81613; Wed, 16 Oct 2002 16:57:12 -0500 (CDT) Subject: Re: to compare journalised file systems From: Stephen Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021016214759.GI27982@plato.local.lan> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 16:53:10 -0500 Message-Id: <1034805191.1461.75.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1028 X-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-16 at 16:47, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:41:20PM -0400, TJ Easter wrote: > > I'm far from an expert level C programmer, but I will examine the code and > > see if I am able to come up with anything and submit patches. > > im fine with C, its just finding my way around the XFS source is quite > a challenge, unless your familier with its internals its quite easy to > get lost. > Not to mention that chattr gets into the filesystem via an ext2 ioctl call. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:01:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:01:15 -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 g9GM1CtG000382 for ; Wed, 16 Oct 2002 15:01:13 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 41139167FA for ; Thu, 17 Oct 2002 00:01:07 +0200 (MEST) Date: Thu, 17 Oct 2002 00:01:07 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021017000107.A21179@wotan.suse.de> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016214759.GI27982@plato.local.lan> User-Agent: Mutt/1.3.22.1i X-archive-position: 1029 X-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 16, 2002 at 01:47:59PM -0800, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:41:20PM -0400, TJ Easter wrote: > > I'm far from an expert level C programmer, but I will examine the code and > > see if I am able to come up with anything and submit patches. > > im fine with C, its just finding my way around the XFS source is quite > a challenge, unless your familier with its internals its quite easy to > get lost. > > i believe the right place for them is the di_flags, defined in > xfs_dinode.h (at the bottom). > > basically as i understand it you need check for these bits in the xfs > diflags and fill the VFS inode flags, the VFS defines bits for > immutable/append-only in a generic way, all XFS needs to do is > inform the VFS that an inode is immutable, it will handle all the > enforcment. No that's not true. The VFS doesn't know about these flags as far as I know. You have to handle them in fs specific code. Even more interesting looking at the source and testing it at least append only is broken for ext2/ext3 - generic_file_llseek doesn't check for it so while you're required to open such a file O_APPEND lseek still works fine. It has probably bitrotted long ago. So if you want to implement it for XFS it may be a good idea to fix it in ext2 first. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:04:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:04: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 g9GM46tG001134 for ; Wed, 16 Oct 2002 15:04:07 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id D6DB014D0B for ; Thu, 17 Oct 2002 00:04:00 +0200 (MEST) Date: Thu, 17 Oct 2002 00:04:00 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021017000400.B21179@wotan.suse.de> References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> <20021016232652.A14553@wotan.suse.de> <20021016215043.GJ27982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016215043.GJ27982@plato.local.lan> User-Agent: Mutt/1.3.22.1i X-archive-position: 1030 X-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 16, 2002 at 01:50:43PM -0800, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 11:26:52PM +0200, Andi Kleen wrote: > > On Wed, Oct 16, 2002 at 12:38:53PM -0800, Ethan Benson wrote: > > > On Wed, Oct 16, 2002 at 05:50:47AM -0400, TJ Easter wrote: > > > > Anyone know if there are plans to impliment the immutable/append-only > > > > options? > > > > > > a couple monthes ago Steve said it looked like it would be pretty easy > > > to do, and without breaking backward compatibilty (since older > > > implementations would simply ignore the bits). he just doesn't really > > > have time, someone with a little experience in the XFS code could > > > probably do it though. > > > > > > immutable, append-only, and the S (sync) bits would be the useful ones. > > > > 'D' for directories is quite useful too, because some mail servers > > assume that everybody has synchronous rename() like traditional BSD FFS. > > your thinking S which can be applied to both files and directories. > > there is no chattr +D at least in my version of it. Then your version is outdated: % chattr usage: chattr [-RV] [-+=AacDdijsSu] [-v version] files... > > > 'd' (don't dump) should be also simple and useful. > > xfs already honors an extended attribute for files only, the > maintainers believe that honoring such a thing for directories is evil. If 'the maintainers' really said such a thing then I disagree with the maintainers. Honoring it for directories should be fine and I can think of applications for it. > > > and of course 'u' if it was implemented (probably a bit more work) > > would clear a major FAQ item on this list. > > not even ext2 supports u. And? Is XFS only limited to things ext2 supports? -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:06:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:06: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 g9GM6JtG001827 for ; Wed, 16 Oct 2002 15:06:20 -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 RAA85423; Wed, 16 Oct 2002 17:06:14 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA26316; Wed, 16 Oct 2002 17:06:13 -0500 (CDT) Subject: Re: to compare journalised file systems From: Stephen Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021016215043.GJ27982@plato.local.lan> References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> <20021016232652.A14553@wotan.suse.de> <20021016215043.GJ27982@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 17:02:11 -0500 Message-Id: <1034805732.1461.82.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1031 X-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-16 at 16:50, Ethan Benson wrote: > > > and of course 'u' if it was implemented (probably a bit more work) > > would clear a major FAQ item on this list. > > not even ext2 supports u. Well, u looks really hard - how do you say you cannot delete a file? What happens when you remove the last directory entry which points at it? That in itself is not an operation on the 'u' file. But, once you remove that last link you just corrupted your filesystem. Seems that not being able to change a file has to include you cannot remove directory entries which point at it. Steve > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:06:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:06:57 -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 g9GM6rtG002132 for ; Wed, 16 Oct 2002 15:06:53 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GM6qVx084362 for ; Wed, 16 Oct 2002 14:06:52 -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 9EE6B3A0B for ; Wed, 16 Oct 2002 14:06:51 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 7AB514104E2; Wed, 16 Oct 2002 14:06:51 -0800 (AKDT) Date: Wed, 16 Oct 2002 14:06:51 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016220651.GK27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <1034805191.1461.75.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mGCtrYeZ202LI9ZG" Content-Disposition: inline In-Reply-To: <1034805191.1461.75.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1032 X-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 --mGCtrYeZ202LI9ZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 04:53:10PM -0500, Stephen Lord wrote: >=20 > Not to mention that chattr gets into the filesystem via an ext2 > ioctl call. this is true, im not sure what reiserfs did, probably they just implemented this ioctl. ideally there should probably be a standardized and generic call for inode flags like this, but since not just implementing the ext2 ioctl is fine. (chattr does not check for ext2 it just calls the ioctl and if the fs doesn't support it the user gets `not a typewriter'). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mGCtrYeZ202LI9ZG 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 iEYEARECAAYFAj2t4vsACgkQJKx7GixEevwZjwCfTtZisyBWurgPQWF9LKodUpIT mtQAn1N5sDJW22oc//NYbd42N0yDxytV =g2HA -----END PGP SIGNATURE----- --mGCtrYeZ202LI9ZG-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:09:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:10:00 -0700 (PDT) Received: from sisko.scot.redhat.com (pc-80-195-35-23-ed.blueyonder.co.uk [80.195.35.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GM9vtG003021 for ; Wed, 16 Oct 2002 15:09:58 -0700 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id g9GM9m800629; Wed, 16 Oct 2002 23:09:48 +0100 Date: Wed, 16 Oct 2002 23:09:48 +0100 From: "Stephen C. Tweedie" To: Andi Kleen Cc: linux-xfs@oss.sgi.com, Stephen Tweedie Subject: Re: to compare journalised file systems Message-ID: <20021016230948.B524@redhat.com> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <20021017000107.A21179@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021017000107.A21179@wotan.suse.de>; from ak@suse.de on Thu, Oct 17, 2002 at 12:01:07AM +0200 X-archive-position: 1033 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Hi, On Thu, Oct 17, 2002 at 12:01:07AM +0200, Andi Kleen wrote: > No that's not true. The VFS doesn't know about these flags as far as > I know. You have to handle them in fs specific code. > > Even more interesting looking at the source and testing it at least append only > is broken for ext2/ext3 - generic_file_llseek doesn't check for it > so while you're required to open such a file O_APPEND lseek still works fine. lseek is ignored on O_APPEND files --- the write always re-seeks to EOF. pwrite goes down that same code path too so it also gets the append enforced. In your testing were you testing real writes, or just the lseeks? Cheers, Stephen From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:10:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:10:20 -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 g9GMAItG003203 for ; Wed, 16 Oct 2002 15:10:18 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GMAGVx089446 for ; Wed, 16 Oct 2002 14:10: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 0D3343A0B for ; Wed, 16 Oct 2002 14:10:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id C246F4104E2; Wed, 16 Oct 2002 14:10:15 -0800 (AKDT) Date: Wed, 16 Oct 2002 14:10:15 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016221015.GL27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <20021017000107.A21179@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TnYVF1hk1c8rpHiF" Content-Disposition: inline In-Reply-To: <20021017000107.A21179@wotan.suse.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1034 X-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 --TnYVF1hk1c8rpHiF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2002 at 12:01:07AM +0200, Andi Kleen wrote: > No that's not true. The VFS doesn't know about these flags as far as=20 > I know. You have to handle them in fs specific code. go look at fs/open.c these calls are using the IS_IMMUTABLE and IS_APPEND macros to check and enforce these flags. > Even more interesting looking at the source and testing it at least appen= d only > is broken for ext2/ext3 - generic_file_llseek doesn't check for it > so while you're required to open such a file O_APPEND lseek still works f= ine. > It has probably bitrotted long ago. that would be a bug to be fixed. > So if you want to implement it for XFS it may be a good idea to fix it=20 > in ext2 first. sure --=20 Ethan Benson http://www.alaska.net/~erbenson/ --TnYVF1hk1c8rpHiF 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 iEYEARECAAYFAj2t48cACgkQJKx7GixEevw31wCfZfeWx0O7RyRKQV6RzlcADJS2 Kc4AoI7DHe3pXjSTvJX/39jW+iknxNxK =Ie/+ -----END PGP SIGNATURE----- --TnYVF1hk1c8rpHiF-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:15:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:15:29 -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 g9GMFRtG004517 for ; Wed, 16 Oct 2002 15:15:27 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GMFPVx096798 for ; Wed, 16 Oct 2002 14:15:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id D2D483A0B for ; Wed, 16 Oct 2002 14:15:24 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9E7904104E2; Wed, 16 Oct 2002 14:15:24 -0800 (AKDT) Date: Wed, 16 Oct 2002 14:15:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021016221524.GM27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> <20021016232652.A14553@wotan.suse.de> <20021016215043.GJ27982@plato.local.lan> <20021017000400.B21179@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C01fF7hLGvN0zd9s" Content-Disposition: inline In-Reply-To: <20021017000400.B21179@wotan.suse.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1035 X-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 --C01fF7hLGvN0zd9s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2002 at 12:04:00AM +0200, Andi Kleen wrote: > > xfs already honors an extended attribute for files only, the > > maintainers believe that honoring such a thing for directories is evil. >=20 > If 'the maintainers' really said such a thing then I disagree with > the maintainers. Honoring it for directories should be fine and I can > think of applications for it. fine look up the list archives if you don't believe me. when the change was first commited Ivan used the word evil specifically when referring to nodump on dirs. there was a more detailed discussion a few monthes later, thier concern appears primarily security. > > not even ext2 supports u. >=20 > And? Is XFS only limited to things ext2 supports? no but the original poster was asking about flags supported by ext2, u is not one of them, and never has been. for the purposes of getting XFS on par with the flags ext2 supports u is not relevant. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --C01fF7hLGvN0zd9s 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 iEYEARECAAYFAj2t5PwACgkQJKx7GixEevwIAgCfZxtSB5kCPdQSs54xlxXi8FZx yP8AoJzLkZCxbzY6TjuLDuBBaXpbArAn =udT/ -----END PGP SIGNATURE----- --C01fF7hLGvN0zd9s-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:16:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:16:03 -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 g9GMG1tG004736 for ; Wed, 16 Oct 2002 15:16:01 -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 RAA91913; Wed, 16 Oct 2002 17:15:56 -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 RAA09874; Wed, 16 Oct 2002 17:15:55 -0500 (CDT) Subject: Re: to compare journalised file systems From: Eric Sandeen To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021016220651.GK27982@plato.local.lan> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <1034805191.1461.75.camel@laptop.americas.sgi.com> <20021016220651.GK27982@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Oct 2002 17:12:28 -0500 Message-Id: <1034806349.15573.51.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1036 X-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 Wed, 2002-10-16 at 17:06, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 04:53:10PM -0500, Stephen Lord wrote: > > > > Not to mention that chattr gets into the filesystem via an ext2 > > ioctl call. > > this is true, im not sure what reiserfs did, probably they just > implemented this ioctl. include/linux/reiserfs_fs.h: /* define following flags to be the same as in ext2, so that chattr(1), lsattr(1) will work with us. */ #define REISERFS_IOC_GETFLAGS EXT2_IOC_GETFLAGS #define REISERFS_IOC_SETFLAGS EXT2_IOC_SETFLAGS -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 Wed Oct 16 15:22:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:22:46 -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 g9GMMhtG006062 for ; Wed, 16 Oct 2002 15:22:44 -0700 Received: from there (host211-32-153-216.net-serv.com [216.153.32.211] (may be forged)) by webcube3.volstate.net (8.11.6/8.11.6) with SMTP id g9GMMgr03666 for ; Wed, 16 Oct 2002 18:22:42 -0400 Message-Id: <200210162222.g9GMMgr03666@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: Root Name Space Date: Wed, 16 Oct 2002 17:18:35 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 1037 X-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 Has anybody realized that since the list option was removed from attr that there is no way to list the attributes in the root name space. The command getfattr does not have an option for listing the attributes of the root namespace. Joe From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:42:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:42:20 -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 g9GMg3tG008854 for ; Wed, 16 Oct 2002 15:42:03 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7A91816C18; Thu, 17 Oct 2002 00:15:49 +0200 (MEST) Date: Thu, 17 Oct 2002 00:15:49 +0200 From: Andi Kleen To: "Stephen C. Tweedie" Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021017001549.A27231@wotan.suse.de> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <20021017000107.A21179@wotan.suse.de> <20021016230948.B524@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016230948.B524@redhat.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1038 X-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 16, 2002 at 11:09:48PM +0100, Stephen C. Tweedie wrote: > Hi, > > On Thu, Oct 17, 2002 at 12:01:07AM +0200, Andi Kleen wrote: > > > No that's not true. The VFS doesn't know about these flags as far as > > I know. You have to handle them in fs specific code. > > > > Even more interesting looking at the source and testing it at least append only > > is broken for ext2/ext3 - generic_file_llseek doesn't check for it > > so while you're required to open such a file O_APPEND lseek still works fine. > > lseek is ignored on O_APPEND files --- the write always re-seeks to > EOF. pwrite goes down that same code path too so it also gets the > append enforced. In your testing were you testing real writes, or > just the lseeks? I was testing a real write. Another hole is pwrite(). % cat tseek.c #include #include main(int ac, char **av) { int fd = open(av[1], O_APPEND|O_WRONLY); if (lseek(fd, 100, SEEK_SET) < 0) perror("expected lseek error"); if (write(fd, "1", 1) < 0) perror("expected write error"); else printf("write succeeded\n"); } % gcc -o tseek tseek.c % dd if=/dev/zero of=/tmp/TEST bs=1k count=10 % su # chattr +a /tmp/TEST % ./tseek /tmp/TEST write succeeded -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 16 15:44:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 15:44:02 -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 g9GMhxtG009467 for ; Wed, 16 Oct 2002 15:44:00 -0700 Received: from erbenson.alaska.net (154-pm3.nwc.alaska.net [209.112.138.154]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g9GMhwVx040200 for ; Wed, 16 Oct 2002 14:43:58 -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 73E543A0B for ; Wed, 16 Oct 2002 14:43:57 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id AF5BE4104E2; Wed, 16 Oct 2002 14:43:57 -0800 (AKDT) Date: Wed, 16 Oct 2002 14:43:57 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Root Name Space Message-ID: <20021016224357.GN27982@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200210162222.g9GMMgr03666@webcube3.volstate.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6yHiY5vv/BiPjcMt" Content-Disposition: inline In-Reply-To: <200210162222.g9GMMgr03666@webcube3.volstate.net> 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: 1039 X-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 --6yHiY5vv/BiPjcMt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2002 at 05:18:35PM -0500, Joe Bacom wrote: > Has anybody realized that since the list option was removed from attr tha= t=20 > there is no way to list the attributes in the root name space. The comma= nd=20 > getfattr does not have an option for listing the attributes of the root= =20 > namespace. yes it does: getfattr -m . foo you must run it as root though, unprivileged users cannot list xfsroot.* attributes. im not sure why the attr command had the list arg removed, surely it can be implemented since getfattr can manage to list attributes... im guessing the attr listing code would have had to be totally rewritten to work with the new syscalls and that effort was simply deferred. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --6yHiY5vv/BiPjcMt 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 iEYEARECAAYFAj2t660ACgkQJKx7GixEevzCGwCghN9LUCqdEkmMuhnpVFHiX7g6 QbUAn0LPuZelWsZ0yVjOSIwf+MDCWs4W =0W56 -----END PGP SIGNATURE----- --6yHiY5vv/BiPjcMt-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 16:08:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 16:08: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 g9GN8FtG013006 for ; Wed, 16 Oct 2002 16:08:15 -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 QAA06439 for ; Wed, 16 Oct 2002 16:08:14 -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 JAA17836 for ; Thu, 17 Oct 2002 09:06:02 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA02975 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 09:06:01 +1000 (EST) Date: Thu, 17 Oct 2002 09:06:00 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: Root Name Space Message-ID: <20021017090600.D302869@wobbly.melbourne.sgi.com> References: <200210162222.g9GMMgr03666@webcube3.volstate.net> <20021016224357.GN27982@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021016224357.GN27982@plato.local.lan>; from erbenson@alaska.net on Wed, Oct 16, 2002 at 02:43:57PM -0800 X-archive-position: 1040 X-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 Wed, Oct 16, 2002 at 02:43:57PM -0800, Ethan Benson wrote: > On Wed, Oct 16, 2002 at 05:18:35PM -0500, Joe Bacom wrote: > > Has anybody realized that since the list option was removed from attr that > > there is no way to list the attributes in the root name space. The command > > getfattr does not have an option for listing the attributes of the root > > namespace. > > yes it does: > > getfattr -m . foo > > you must run it as root though, unprivileged users cannot list > xfsroot.* attributes. > > im not sure why the attr command had the list arg removed, surely it > can be implemented since getfattr can manage to list attributes... The attr list was based on the IRIX list, which is not just a list but a list-and-give-all-attr-sizes in one op. This is quite painful to code in userspace on top of the revised APIs (but it could be done, you're right). getfattr is the prefered mechanism, it is a fair bit more "feature-packed" than attr is - I simply made attr work as best I could to try to give existing users some backwards compatibility, but I drew the line at the list operation. > im guessing the attr listing code would have had to be totally > rewritten to work with the new syscalls and that effort was simply > deferred. Not really defered - I chose not to to do it and don't have any plan to do so. Others are welcome to have at it though, of course, and I'll add in any patch that implement it for sure. Since getfattr provides a similar capability, I doubt its really interesting to anyone though. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 16 16:52:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 16:52:31 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9GNqTtG018406 for ; Wed, 16 Oct 2002 16:52:29 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9GNqTgG018405 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 16:52:29 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9GNqStG018391 for ; Wed, 16 Oct 2002 16:52:28 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9GNXxGL016563; Wed, 16 Oct 2002 16:33:59 -0700 Date: Wed, 16 Oct 2002 16:33:59 -0700 Message-Id: <200210162333.g9GNXxGL016563@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 181] fsx produces file system corruption X-Bugzilla-Reason: AssignedTo X-archive-position: 1041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |cattelan@thebarn.com ------- Additional Comments From cattelan@thebarn.com 2002-10-16 16:05 ------- Subject: Re: New: fsx produces file system corruption more spam On Wed, 2002-10-16 at 17:17, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 > > Summary: fsx produces file system corruption > Product: Linux XFS > Version: 1.2.x > Platform: All > OS/Version: Linux > Status: NEW > Severity: normal > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: cattelan@thebarn.com > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > bob house of code > Description of Problem: > fsx fails on XFS with blocks sizes smaller than page size > > > How Reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual Results: > > > Expected Results: > > > Additional Information: > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. ------- Additional Comments From cattelan@thebarn.com 2002-10-16 16:07 ------- Subject: Re: New: fsx produces file system corruption more spam On Wed, 2002-10-16 at 17:17, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 > > Summary: fsx produces file system corruption > Product: Linux XFS > Version: 1.2.x > Platform: All > OS/Version: Linux > Status: NEW > Severity: normal > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: cattelan@thebarn.com > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > bob house of code > Description of Problem: > fsx fails on XFS with blocks sizes smaller than page size > > > How Reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual Results: > > > Expected Results: > > > Additional Information: > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 16 17:35:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 17:35:14 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H0Z9tG024450 for ; Wed, 16 Oct 2002 17:35:09 -0700 Received: (qmail 11834 invoked by uid 500); 17 Oct 2002 00:34:43 -0000 Subject: Is there something special I need to do? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mLGIliQW4AairPXwt79G" Organization: Coremetrics, Inc. Message-Id: <1034814882.7259.114.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 16 Oct 2002 19:34:43 -0500 X-archive-position: 1042 X-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 --=-mLGIliQW4AairPXwt79G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable To use LABEL=3D for xfs mountpoints? Doesn't seem to be working for me. I formatted all my fs, then went back and did xfs_admin -L name /dev/sdN I then added LABEL=3Dname /mountpoint xfs defaults 1 2 and I can't mount LABEL=3Dname. Did I do something wrong in that scenario? --=20 Austin Gonyou Coremetrics, Inc. --=-mLGIliQW4AairPXwt79G 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 iD8DBQA9rgWi94g6ZVmFMoIRAvyeAKDBBtlspRjdRH7OvMucfh0HP9U0xQCfc+Jg pL3ZdGToDtNNdMrGlsbMoLg= =8gSm -----END PGP SIGNATURE----- --=-mLGIliQW4AairPXwt79G-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 17:44:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 17:44:58 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H0istG025874 for ; Wed, 16 Oct 2002 17:44:54 -0700 Received: (qmail 12939 invoked by uid 500); 17 Oct 2002 00:44:20 -0000 Subject: Re: Is there something special I need to do? From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1034814882.7259.114.camel@UberGeek.coremetrics.com> References: <1034814882.7259.114.camel@UberGeek.coremetrics.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JiXp6yPd6569wVAWiS/C" Organization: Coremetrics, Inc. Message-Id: <1034815460.7264.117.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 16 Oct 2002 19:44:20 -0500 X-archive-position: 1043 X-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 --=-JiXp6yPd6569wVAWiS/C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-10-16 at 19:34, Austin Gonyou wrote: > To use LABEL=3D for xfs mountpoints? > Doesn't seem to be working for me. I formatted all my fs, then went back > and did xfs_admin -L name /dev/sdN >=20 > I then added LABEL=3Dname /mountpoint xfs defaults 1 2 and I can't mount > LABEL=3Dname. Did I do something wrong in that scenario? as a side note to this, I didn't make any partitions, I'm just using the whole disk. I dunno if that makes a difference but thought I'd ask. --=20 Austin Gonyou Coremetrics, Inc. --=-JiXp6yPd6569wVAWiS/C 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 iD8DBQA9rgfk94g6ZVmFMoIRAqsWAJ4kFT6AJnOxXl1c+1/oa+JbW7sfmQCeMF5q UzXTpfFUoSWSKtNDntwnyAQ= =Mo1L -----END PGP SIGNATURE----- --=-JiXp6yPd6569wVAWiS/C-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 17:52:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 17:52: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 g9H0qHtG027050 for ; Wed, 16 Oct 2002 17:52:18 -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 TAA75467; Wed, 16 Oct 2002 19:52:12 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA63702; Wed, 16 Oct 2002 19:52:11 -0500 (CDT) Subject: Re: Is there something special I need to do? From: Stephen Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034814882.7259.114.camel@UberGeek.coremetrics.com> References: <1034814882.7259.114.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 19:48:08 -0500 Message-Id: <1034815690.1165.103.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1044 X-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-16 at 19:34, Austin Gonyou wrote: > To use LABEL= for xfs mountpoints? > Doesn't seem to be working for me. I formatted all my fs, then went back > and did xfs_admin -L name /dev/sdN > > I then added LABEL=name /mountpoint xfs defaults 1 2 and I can't mount > LABEL=name. Did I do something wrong in that scenario? First, how long a string, xfs has room for 14 chars, second, how recent is your mount command, it has to be able to understand xfs on disk format. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 17:53:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 17:53: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 g9H0rYtG027572 for ; Wed, 16 Oct 2002 17:53: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 TAA07445; Wed, 16 Oct 2002 19:53:29 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-2.corp.sgi.com [134.15.64.2]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA53706; Wed, 16 Oct 2002 19:53:28 -0500 (CDT) Subject: Re: Is there something special I need to do? From: Stephen Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034815460.7264.117.camel@UberGeek.coremetrics.com> References: <1034814882.7259.114.camel@UberGeek.coremetrics.com> <1034815460.7264.117.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 19:49:26 -0500 Message-Id: <1034815767.1107.105.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1045 X-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-16 at 19:44, Austin Gonyou wrote: > On Wed, 2002-10-16 at 19:34, Austin Gonyou wrote: > > To use LABEL= for xfs mountpoints? > > Doesn't seem to be working for me. I formatted all my fs, then went back > > and did xfs_admin -L name /dev/sdN > > > > I then added LABEL=name /mountpoint xfs defaults 1 2 and I can't mount > > LABEL=name. Did I do something wrong in that scenario? > > as a side note to this, I didn't make any partitions, I'm just using the > whole disk. I dunno if that makes a difference but thought I'd ask. Not sure, the mount command scans everything which appears in /proc/partitions if your filesystem is in there it should work, provided the items I just mentioned are taken care of. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:01:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:01:46 -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 g9H11itG028807 for ; Wed, 16 Oct 2002 18:01:44 -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 SAA04635 for ; Wed, 16 Oct 2002 18:01:14 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19111 for ; Thu, 17 Oct 2002 10:59:58 +1000 Received: from omen.melbourne.sgi.com (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with SMTP id KAA41852 for ; Thu, 17 Oct 2002 10:59:57 +1000 (EST) Date: Thu, 17 Oct 2002 10:59:57 +1000 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-Id: <20021017105957.6d3af7f2.ivanr@sgi.com> In-Reply-To: <20021016221524.GM27982@plato.local.lan> References: <20021016085626.GB27982@plato.local.lan> <20021016203853.GH27982@plato.local.lan> <20021016232652.A14553@wotan.suse.de> <20021016215043.GJ27982@plato.local.lan> <20021017000400.B21179@wotan.suse.de> <20021016221524.GM27982@plato.local.lan> Organization: SGI X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 16 Oct 2002 14:15:24 -0800, Ethan Benson wrote: > On Thu, Oct 17, 2002 at 12:04:00AM +0200, Andi Kleen wrote: > > > xfs already honors an extended attribute for files only, the > > > maintainers believe that honoring such a thing for directories is > > > evil. > > > > If 'the maintainers' really said such a thing then I disagree with > > the maintainers. Honoring it for directories should be fine and I > > can think of applications for it. > > fine look up the list archives if you don't believe me. when the > change was first commited Ivan used the word evil specifically when > referring to nodump on dirs. there was a more detailed discussion a > few monthes later, thier concern appears primarily security. By the "maintainers" you mean me, since I was the one that implemented it. I don't remember using the word 'evil' -- obviously I was just grandstanding. It wasn't done for directories for 2 main reasons, that I recall: 1. Security. I didn't like the idea of the owner of a directory deciding whether files, that might be hidden in the depths of a directory tree and could be owned by others, get dumped or not. To allow this would be ... evil! :) 2. Simplicity and performance. To expand this for directories in xfsdump would mean a fair bit more work (which would not have been approved as a project), and probably a real performance hit during dump processing. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:05:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:05:54 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H15ptG029650 for ; Wed, 16 Oct 2002 18:05:51 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9H15jf04925 for ; Wed, 16 Oct 2002 21:05:45 -0400 Message-ID: <3DAE0CE9.17F4E8AA@splentec.com> Date: Wed, 16 Oct 2002 21:05:45 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page()) References: <1034780582.15709.5.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: > > Could you guys try this patch, it should detect some stack overflows, in > case that's what you're hitting... Meanwhile, perhaps we can set up a > similar test here. > Tried it. Same bug. Here's is our setup -- more detailed: 2.4.19 stock, ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19/xfs-2.4.19-all-i386.bz2 from 2002-09-27, 4:22 UTC. Using the LVM from the stock kernel. The lvm commands are the ones from 1.1-rc2 and you may see some not understood ioctls, but we've ignored them. This is /etc/raidtab: raiddev /dev/md0 raid-level 5 nr-raid-disks 4 nr-spare-disks 0 persistent-superblock 1 parity-algorithm left-symmetric chunk-size 64 device /dev/sda raid-disk 0 device /dev/sdb raid-disk 1 device /dev/sdc raid-disk 2 device /dev/sdd raid-disk 3 ------------------------------------------------------- This is the script to create the vg/lv device: #!/bin/bash . ./DEVICE_NAMES DEVICE=/dev/md0 pvcreate -ffy $DEVICE vgcreate $VG -s32M -p255 -l256 $DEVICE lvcreate -L1G -n${LV} $VG -------------------------------------------------------- This is the script to mount the device: #!/bin/bash . ./DEVICE_NAMES # FSPROG=mke2fs # FSTYPE=ext2 FSPROG="mkfs.xfs -f" FSTYPE=xfs MOUNTP=/mnt/disk echo Unmounting... umount ${MOUNTP} echo Sleeping for 2... sleep 2 echo Doing work... ${FSPROG} /dev/${VG}/${LV} echo "sleeping ..." sleep 3 mount -t ${FSTYPE} -onoatime,nodiratime,usrquota,grpquota /dev/${VG}/${LV} ${MOUNTP} ---------------------------------------------- And this is DEVICE_NAMES file: # VG= the name of the vol group; LV= the name of the log. vol. VG=vg0 LV=lv0 ---------------------------------------------- The kernel has NO quota compiled in, only the one from xfs and it has HIGHMEM enabled to 4 GB. Try this set up, you should get the same bug and the same stack trace. In the mean time I'll the the latest CVS trunk, which is what you tried I think. -- Luben From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:10:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:10:45 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H1AgtG030449 for ; Wed, 16 Oct 2002 18:10:42 -0700 Received: (qmail 14850 invoked by uid 500); 17 Oct 2002 01:10:11 -0000 Subject: Re: Is there something special I need to do? From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034815767.1107.105.camel@laptop.americas.sgi.com> References: <1034815767.1107.105.camel@laptop.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TSdbvb2l+8T7dtZtIIe+" Organization: Coremetrics, Inc. Message-Id: <1034817011.7264.119.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 16 Oct 2002 20:10:11 -0500 X-archive-position: 1048 X-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 --=-TSdbvb2l+8T7dtZtIIe+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-10-16 at 19:49, Stephen Lord wrote: > ... > > > I then added LABEL=3Dname /mountpoint xfs defaults 1 2 and I can't > mount > > > LABEL=3Dname. Did I do something wrong in that scenario? > >=20 > > as a side note to this, I didn't make any partitions, I'm just using > the > > whole disk. I dunno if that makes a difference but thought I'd ask. >=20 > Not sure, the mount command scans everything which appears in > /proc/partitions if your filesystem is in there it should work, > provided the items I just mentioned are taken care of. Gotcha. I'll check it out. :) > Steve --=20 Austin Gonyou Coremetrics, Inc. --=-TSdbvb2l+8T7dtZtIIe+ 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 iD8DBQA9rg3z94g6ZVmFMoIRApf5AKDQbVLDyOC/wIjawK/3Im9N6khJkACgy5lD QjBtbLq4clN9c7TgwD9P9rU= =UCjA -----END PGP SIGNATURE----- --=-TSdbvb2l+8T7dtZtIIe+-- From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:26:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:26:39 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H1QatG032176 for ; Wed, 16 Oct 2002 18:26:37 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4F94D4B7E9B for ; Wed, 16 Oct 2002 20:26:43 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D74874B7E9A; Wed, 16 Oct 2002 20:26:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C88D3C026AF for ; Wed, 16 Oct 2002 20:26:41 -0500 (EST) Date: Wed, 16 Oct 2002 20:26:37 -0500 (EST) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: [Bug 181] fsx produces file system corruption (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Interesting...the list is the owner for this issue? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 ---------- Forwarded message ---------- Date: Wed, 16 Oct 2002 16:33:59 -0700 From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 181] fsx produces file system corruption http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |cattelan@thebarn.com ------- Additional Comments From cattelan@thebarn.com 2002-10-16 16:05 ------- Subject: Re: New: fsx produces file system corruption more spam On Wed, 2002-10-16 at 17:17, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 > > Summary: fsx produces file system corruption > Product: Linux XFS > Version: 1.2.x > Platform: All > OS/Version: Linux > Status: NEW > Severity: normal > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: cattelan@thebarn.com > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > bob house of code > Description of Problem: > fsx fails on XFS with blocks sizes smaller than page size > > > How Reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual Results: > > > Expected Results: > > > Additional Information: > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. ------- Additional Comments From cattelan@thebarn.com 2002-10-16 16:07 ------- Subject: Re: New: fsx produces file system corruption more spam On Wed, 2002-10-16 at 17:17, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=181 > > Summary: fsx produces file system corruption > Product: Linux XFS > Version: 1.2.x > Platform: All > OS/Version: Linux > Status: NEW > Severity: normal > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: cattelan@thebarn.com > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > bob house of code > Description of Problem: > fsx fails on XFS with blocks sizes smaller than page size > > > How Reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual Results: > > > Expected Results: > > > Additional Information: > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:43:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:43: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 g9H1hqtG001595 for ; Wed, 16 Oct 2002 18:43:52 -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 UAA40876; Wed, 16 Oct 2002 20:43: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 UAA58268; Wed, 16 Oct 2002 20:43:45 -0500 (CDT) Date: Wed, 16 Oct 2002 20:40:17 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 181] fsx produces file system corruption (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1050 X-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 Well, here's the idea. In the past, bugs have gone to the list. Sometimes discussion happens, sometimes they get fixed, sometimes they get lost. We've got bugzilla running now, which will be a much better way to track bugs, but I'd like the chance for the list to see them as in the past, so that we can get some discussion & possibly triage. So, the thought was that if new bugs go to the list as well, we can track them in bugzilla, but also get the collective knowledge of the list to help eyeball them. Sooo Russell is trying to set things up to accomplish this. -Eric On Wed, 16 Oct 2002, Mike Burger wrote: > Interesting...the list is the owner for this issue? > > -- > Mike Burger > http://www.bubbanfriends.org From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:52:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:52:32 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H1qUtG003325 for ; Wed, 16 Oct 2002 18:52:30 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H1qUmi003322 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 18:52:30 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H1qStI003307 for ; Wed, 16 Oct 2002 18:52:29 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H1p5aZ003175; Wed, 16 Oct 2002 18:51:05 -0700 Date: Wed, 16 Oct 2002 18:51:05 -0700 Message-Id: <200210170151.g9H1p5aZ003175@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 182] New: Hitting the BUG() in filemap.c:843 (in unlock_page()) X-Bugzilla-Reason: AssignedTo X-archive-position: 1051 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=182 Summary: Hitting the BUG() in filemap.c:843 (in unlock_page()) Product: Linux XFS Version: 1.1.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: luben@splentec.com If this is a userspace bug, what version of the package are you using: xfs 1.1 for 2.4.19 generated on 2002-09-27 4:22 UTC What kernel are you using: 2.4.19 stock Where did the XFS code come from? (CVS, Linus, your distribution, etc): ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19/xfs-2.4.19-all-i386.bz2 Description of Problem: We have this scenario: xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD. When md is set up with 3 (odd #) devices, then a mount sleeps indefinitely on down(), and when md is set up with 4 devices, then the kernel oopses at filemap.c:843 in unlock_page() the BUG() statement. For the complete story please see the linux-xfs mailing list and the message with title: Re: hitting the BUG() in filemap.c:843 (in unlock_page()), dated Wed, 16 Oct 2002 21:05:45 -0400. How Reproducible: set up md in raid 5, no spares, block size 64, 4 devices to hit BUG(), 3 devices to sleep indefinitely, make a single lv/vg on top of the md device and try to mount it with xfs, options: onoatime,nodiratime,usrquota,grpquota. Please see the mailing list for the scripts and all the parameters. Steps to Reproduce: Please see above. 1. 2. 3. Actual Results: hitting the BUG() in filemap.c:843 or sleeping indefinitely -- 4 or 3 disks in md resepectively. Expected Results: sucessful mount! Additional Information: Please see the linux-xfs mailing list at the message indicated above where I've included the exact (!) parameters of the raid array, the vg/lv and the xfs mount. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 16 18:57:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 18:57:33 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H1vVtG004798 for ; Wed, 16 Oct 2002 18:57:31 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9H1vPf05220 for ; Wed, 16 Oct 2002 21:57:25 -0400 Message-ID: <3DAE1905.FE553215@splentec.com> Date: Wed, 16 Oct 2002 21:57:25 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page()) References: <1034785757.16062.17.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: > > FWIW, I tried 3 and 4 LV devices in software raid 5, and both mounted > successfully. This is with CVS code on an SMP system, with the LVM code > that came from 2.4.19... > > Could you please file this bug in bugzilla, at > http://oss.sgi.com/bugzilla/ ? Has been submitted. Bug# 182. Please also see my posting with all the details on raid setup, lv setup, xfs mount options, etc. -- Luben From owner-linux-xfs@oss.sgi.com Wed Oct 16 19:08:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 19:08:06 -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 g9H283tG007466 for ; Wed, 16 Oct 2002 19:08:03 -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 VAA25250; Wed, 16 Oct 2002 21:07:58 -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 VAA02283; Wed, 16 Oct 2002 21:07:57 -0500 (CDT) Date: Wed, 16 Oct 2002 21:04:29 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Austin Gonyou cc: Stephen Lord , Subject: Re: Is there something special I need to do? In-Reply-To: <1034817011.7264.119.camel@UberGeek.coremetrics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1053 X-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 Dunno, I tested a whole disk with xfs and ext2, and neither could mount by label. -Eric On 16 Oct 2002, Austin Gonyou wrote: > On Wed, 2002-10-16 at 19:49, Stephen Lord wrote: > > ... > > > > I then added LABEL=name /mountpoint xfs defaults 1 2 and I can't > > mount > > > > LABEL=name. Did I do something wrong in that scenario? > > > > > > as a side note to this, I didn't make any partitions, I'm just using > > the > > > whole disk. I dunno if that makes a difference but thought I'd ask. > > > > Not sure, the mount command scans everything which appears in > > /proc/partitions if your filesystem is in there it should work, > > provided the items I just mentioned are taken care of. > > Gotcha. I'll check it out. :) > > > > Steve > > > > -- > Austin Gonyou > Coremetrics, Inc. > From owner-linux-xfs@oss.sgi.com Wed Oct 16 19:14:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 19:14:40 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H2EbtG008365 for ; Wed, 16 Oct 2002 19:14:38 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id CE6064B7E9B; Wed, 16 Oct 2002 21:14:44 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 3C2054B7E9A; Wed, 16 Oct 2002 21:14:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 22DBBC026AF; Wed, 16 Oct 2002 21:14:43 -0500 (EST) Date: Wed, 16 Oct 2002 21:14:42 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 181] fsx produces file system corruption (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Ok...was just curious about it..thanks. On Wed, 16 Oct 2002, Eric Sandeen wrote: > Well, here's the idea. > > In the past, bugs have gone to the list. Sometimes discussion happens, > sometimes they get fixed, sometimes they get lost. > > We've got bugzilla running now, which will be a much better way to track bugs, > but I'd like the chance for the list to see them as in the past, so that we can > get some discussion & possibly triage. > > So, the thought was that if new bugs go to the list as well, we can track > them in bugzilla, but also get the collective knowledge of the list to help > eyeball them. > > Sooo Russell is trying to set things up to accomplish this. > > -Eric > > On Wed, 16 Oct 2002, Mike Burger wrote: > > > Interesting...the list is the owner for this issue? > > > > -- > > Mike Burger > > http://www.bubbanfriends.org > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 From owner-linux-xfs@oss.sgi.com Wed Oct 16 19:52:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 19:52:33 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H2qUtG015208 for ; Wed, 16 Oct 2002 19:52:30 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H2qUEf015206 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 19:52:30 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H2qTtG015176 for ; Wed, 16 Oct 2002 19:52:29 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H2cWFh013450; Wed, 16 Oct 2002 19:38:32 -0700 Date: Wed, 16 Oct 2002 19:38:32 -0700 Message-Id: <200210170238.g9H2cWFh013450@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 183] New: warings when compiling kernel X-Bugzilla-Reason: AssignedTo X-archive-position: 1055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=183 Summary: warings when compiling kernel Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ajayr@krithika.net If this is a userspace bug, what version of the package are you using: What kernel are you using kernel-2.4.18-14SGI_XFS_1.2a1.i686: Where did the XFS code come from? (CVS, Linus, your distribution, etc): 1.2a1 Description of Problem: warnings when I recompile XFS kernel source for athlon on RH8 How Reproducible: using GCC 3.2 from RH8 to recompile kernel Steps to Reproduce: 1. 2. 3. Actual Results: lots of warnings Expected Results: none related to march and falign etc Additional Information: JAM kernels have a patch for compiling with gcc 3, I have adapted that for the 1.2a kernel --- linux/arch/i386/Makefile.orig 2002-10-12 08:28:31.000000000 +0530 +++ linux/arch/i386/Makefile 2002-10-12 08:41:23.000000000 +0530 @@ -43,19 +43,19 @@ endif ifdef CONFIG_M586MMX -CFLAGS += -march=i586 +CFLAGS += $(shell if $(CC) -march=pentium-mmx -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium-mmx"; else echo "-marc h=i586"; fi) endif ifdef CONFIG_M686 -CFLAGS += -march=i686 +CFLAGS += $(shell if $(CC) -march=pentium2 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium2"; else echo "-march=i686 "; fi) endif ifdef CONFIG_MPENTIUMIII -CFLAGS += -march=i686 +CFLAGS += $(shell if $(CC) -march=pentium3 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium3"; else echo "-march=i686 "; fi) endif ifdef CONFIG_MPENTIUM4 -CFLAGS += -march=i686 +CFLAGS += $(shell if $(CC) -march=pentium4 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=pentium4"; else echo "-march=i686 "; fi) endif ifdef CONFIG_MK6 @@ -63,7 +63,7 @@ endif ifdef CONFIG_MK7 -CFLAGS += -march=i686 -malign-functions=4 +CFLAGS += $(shell if $(CC) -march=athlon -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-march=athlon"; else echo "-march=i686 -ma lign-functions=4"; fi) endif ifdef CONFIG_MCRUSOE ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 16 20:52:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 20:52:33 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H3qVtG022454 for ; Wed, 16 Oct 2002 20:52:31 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H3qUXB022453 for linux-xfs@oss.sgi.com; Wed, 16 Oct 2002 20:52:30 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H3qTtI022439 for ; Wed, 16 Oct 2002 20:52:29 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H3a26R021590; Wed, 16 Oct 2002 20:36:02 -0700 Date: Wed, 16 Oct 2002 20:36:02 -0700 Message-Id: <200210170336.g9H3a26R021590@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 183] warings when compiling kernel X-Bugzilla-Reason: AssignedTo X-archive-position: 1056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=183 ------- Additional Comments From sandeen@sgi.com 2002-10-16 20:36 ------- Are the warnings you see with or without the patch you added to the bug? Are the warnings unique to the xfs code, or do you see them for all kernel components? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 16 23:13:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 23:13:09 -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 g9H6D3tG001339 for ; Wed, 16 Oct 2002 23:13:03 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) 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 XAA00931 for ; Wed, 16 Oct 2002 23:12:57 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g9H6Cuv31993; Thu, 17 Oct 2002 16:12:56 +1000 Date: Thu, 17 Oct 2002 16:12:56 +1000 From: Keith Owens Message-Id: <200210170612.g9H6Cuv31993@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.3-2.4.19 common-4, i386-5 X-archive-position: 1057 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync with kdb v2.3-2.4.19 common-4, i386-5 Date: Wed Oct 16 23:11:47 PDT 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:130240a linux/Documentation/kdb/kdb_sr.man - 1.1 linux/arch/i386/kernel/traps.c - 1.46 linux/arch/i386/config.in - 1.72 linux/Documentation/Configure.help - 1.139 linux/kdb/kdb_bt.c - 1.12 linux/kdb/kdb_bp.c - 1.12 linux/kdb/modules/kdbm_vm.c - 1.20 linux/kdb/Makefile - 1.14 linux/include/linux/kdbprivate.h - 1.20 linux/include/linux/kdb.h - 1.24 linux/kdb/kdbsupport.c - 1.14 linux/kdb/kdbmain.c - 1.29 linux/include/asm-i386/kdb.h - 1.13 linux/kdb/kdb_io.c - 1.15 linux/include/asm-i386/kdbprivate.h - 1.17 linux/arch/i386/kdb/kdba_id.c - 1.13 linux/Documentation/kdb/kdb.mm - 1.15 linux/Documentation/kdb/kdb_bt.man - 1.8 linux/kdb/kdb_id.c - 1.15 linux/arch/i386/kdb/kdbasupport.c - 1.21 linux/arch/i386/kdb/kdba_io.c - 1.18 linux/arch/i386/kdb/Makefile - 1.11 linux/arch/i386/kdb/kdba_bt.c - 1.16 linux/arch/i386/kdb/kdba_bp.c - 1.14 linux/kdb/modules/kdbm_pg.c - 1.59 linux/kdb/ChangeLog - 1.21 linux/arch/i386/kdb/ChangeLog - 1.10 From owner-linux-xfs@oss.sgi.com Wed Oct 16 23:15:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Oct 2002 23:15:05 -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 g9H6F3tG001755 for ; Wed, 16 Oct 2002 23:15:03 -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 XAA05112 for ; Wed, 16 Oct 2002 23:15:02 -0700 (PDT) mail_from (mg@sgi.com) Received: from localhost (mg@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA37093; Thu, 17 Oct 2002 16:13:41 +1000 (EST) X-Authentication-Warning: snort.melbourne.sgi.com: mg owned process doing -bs Date: Thu, 17 Oct 2002 16:13:41 +1000 From: Mike Gigante X-X-Sender: mg@snort.melbourne.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 181] fsx produces file system corruption (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: linux-xfs Now that is a real community programming model! :-) Mike On Wed, 16 Oct 2002, Mike Burger wrote: > Interesting...the list is the owner for this issue? > > -- > Mike Burger > http://www.bubbanfriends.org > > Visit the Dog Pound II BBS > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 > From owner-linux-xfs@oss.sgi.com Thu Oct 17 00:14:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 00:14:43 -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 g9H7EEtG008231 for ; Thu, 17 Oct 2002 00:14:25 -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 g9H7BKD12744; Thu, 17 Oct 2002 10:11:20 +0300 Date: Thu, 17 Oct 2002 10:13:37 +0300 From: 辝ref Tufan 辝n To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2Pre and nfs problem Message-Id: <20021017101337.08c94359.tufan@itu.edu.tr> In-Reply-To: <20021017073316.A302869@wobbly.melbourne.sgi.com> References: <20021011124432.253ca55a.tufan@itu.edu.tr> <1034352726.1162.7.camel@rose.americas.sgi.com> <20021012140349.3c28bcc9.tufan@itu.edu.tr> <20021016115430.724d3b18.tufan@itu.edu.tr> <1034779623.15573.0.camel@stout.americas.sgi.com> <20021017073316.A302869@wobbly.melbourne.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 g9H7BKD12744 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9H7EatG008256 X-archive-position: 1059 X-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 Hi,,, On Thu, 17 Oct 2002 07:33:16 +1000 Nathan Scott wrote: > 990 (EFSCORRUPTED) can be generated by xfs_repair itself (via > libxfs). Its not supposed to happen, but it can. :( Running > ltrace on xfs_repair would help to find the offending routine > in libxfs. I will do it when this evening.. I will post he results... -- 辝ref Tufan 辝n 軹-B軩B Sistem Destek Grubu From owner-linux-xfs@oss.sgi.com Thu Oct 17 00:21:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 00:21:40 -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 g9H7LbtG009225 for ; Thu, 17 Oct 2002 00:21:38 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 6AF10147CB; Thu, 17 Oct 2002 09:21:32 +0200 (MEST) Date: Thu, 17 Oct 2002 09:21:31 +0200 From: Andi Kleen To: Eric Sandeen Cc: Austin Gonyou , Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Is there something special I need to do? Message-ID: <20021017092131.A29129@wotan.suse.de> References: <1034817011.7264.119.camel@UberGeek.coremetrics.com> 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: 1060 X-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 16, 2002 at 09:04:29PM -0500, Eric Sandeen wrote: > Dunno, I tested a whole disk with xfs and ext2, and neither could mount > by label. That's because whole disks are not in /proc/partitions. -And From owner-linux-xfs@oss.sgi.com Thu Oct 17 00:41:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 00:41:46 -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 g9H7fetG011216 for ; Thu, 17 Oct 2002 00:41:40 -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 AAA01938 for ; Thu, 17 Oct 2002 00:41:38 -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 RAA22263; Thu, 17 Oct 2002 17:40:20 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA03107; Thu, 17 Oct 2002 17:40:18 +1000 (EST) Date: Thu, 17 Oct 2002 17:40:18 +1000 From: Nathan Scott To: Andi Kleen , aeb@cwi.nl Cc: Eric Sandeen , Austin Gonyou , Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: Is there something special I need to do? Message-ID: <20021017174018.C294615@wobbly.melbourne.sgi.com> References: <1034817011.7264.119.camel@UberGeek.coremetrics.com> <20021017092131.A29129@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021017092131.A29129@wotan.suse.de>; from ak@suse.de on Thu, Oct 17, 2002 at 09:21:31AM +0200 X-archive-position: 1061 X-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 Thu, Oct 17, 2002 at 09:21:31AM +0200, Andi Kleen wrote: > On Wed, Oct 16, 2002 at 09:04:29PM -0500, Eric Sandeen wrote: > > Dunno, I tested a whole disk with xfs and ext2, and neither could mount > > by label. > > That's because whole disks are not in /proc/partitions. > They are, the problem is mount explicitly skips them (see util-linux/mount/mount_by_label.c::uuid_cache_init...) ... for(s = ptname; *s; s++); if (isdigit(s[-1])) { ...[do good stuff]... } and right there we've skipped over anything thats not a partition. Why mount does this, I have no idea - we'll have to ask Andries (aeb@cwi.nl), the util-linux guru. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 17 00:53:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 00:53:14 -0700 (PDT) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H7rAtG012199 for ; Thu, 17 Oct 2002 00:53:11 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g9H7rgA14636; Thu, 17 Oct 2002 09:53:42 +0200 Date: Thu, 17 Oct 2002 09:53:42 +0200 (CEST) From: Matteo Centonza To: Ivan Rayner cc: linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems In-Reply-To: <20021017105957.6d3af7f2.ivanr@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi, On Thu, 17 Oct 2002, Ivan Rayner wrote: > On Wed, 16 Oct 2002 14:15:24 -0800, Ethan Benson wrote: > > > On Thu, Oct 17, 2002 at 12:04:00AM +0200, Andi Kleen wrote: > > > > xfs already honors an extended attribute for files only, the > > > > maintainers believe that honoring such a thing for directories is > > > > evil. > > > > > > If 'the maintainers' really said such a thing then I disagree with > > > the maintainers. Honoring it for directories should be fine and I > > > can think of applications for it. > > > > fine look up the list archives if you don't believe me. when the > > change was first commited Ivan used the word evil specifically when > > referring to nodump on dirs. there was a more detailed discussion a > > few monthes later, thier concern appears primarily security. > > By the "maintainers" you mean me, since I was the one that implemented > it. > > I don't remember using the word 'evil' -- obviously I was just > grandstanding. > > It wasn't done for directories for 2 main reasons, that I recall: > > 1. Security. I didn't like the idea of the owner of a directory > deciding whether files, that might be hidden in the depths of > a directory tree and could be owned by others, get dumped or > not. To allow this would be ... evil! :) as i argued before http://marc.theaimsgroup.com/?l=linux-xfs&m=102370432004601&w=2 security concerns are blown away if you thing this as administrator stuff (via a reserved namespace using attributes). > 2. Simplicity and performance. To expand this for directories in > xfsdump would mean a fair bit more work (which would not have > been approved as a project), and probably a real performance > hit during dump processing. These are both real concerns. Regarding performance, probably you can trigger the extra directory pruning stage or whatever else via a flag to xfsdump. Just speculating ;). Anyway, thanks the very good work. -m From owner-linux-xfs@oss.sgi.com Thu Oct 17 01:40:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 01:40:42 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9H8eZtG016366 for ; Thu, 17 Oct 2002 01:40:35 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9H8eZvF016364 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 01:40:35 -0700 Received: from swathi.krithika.net ([202.88.158.15]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H8eTtG016346 for ; Thu, 17 Oct 2002 01:40:32 -0700 Received: from localhost.krithika.net (localhost [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id CBE724EDA43; Thu, 17 Oct 2002 14:10:26 +0530 (IST) Subject: [BUG 183] here is the patch From: Ajay Ramaswamy To: Eric Sandeen Cc: xfs-master@oss.sgi.com Content-Type: multipart/mixed; boundary="=-3agiF5hh511wQNrrjvSG" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 17 Oct 2002 14:10:25 +0530 Message-Id: <1034844026.9359.4.camel@swathi.krithika.net> Mime-Version: 1.0 X-archive-position: 1063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajayr@krithika.net Precedence: bulk X-list: linux-xfs --=-3agiF5hh511wQNrrjvSG Content-Type: text/plain Content-Transfer-Encoding: 7bit Eric, 0. here is the patch the bugzilla one is wrapped and unusable 1. The warnings are there without the patch. 2. The warnings are there in other parts of the kernel too. Thanks & regards Ajay --=-3agiF5hh511wQNrrjvSG Content-Disposition: attachment; filename=linux-2.4.19-gcc3-warn.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=linux-2.4.19-gcc3-warn.patch; charset=UTF-8 --- linux/arch/i386/Makefile.orig 2002-10-12 08:28:31.000000000 +0530 +++ linux/arch/i386/Makefile 2002-10-12 08:41:23.000000000 +0530 @@ -43,19 +43,19 @@ endif =20 ifdef CONFIG_M586MMX -CFLAGS +=3D -march=3Di586 +CFLAGS +=3D $(shell if $(CC) -march=3Dpentium-mmx -S -o /dev/null -xc /dev= /null >/dev/null 2>&1; then echo "-march=3Dpentium-mmx"; else echo "-march= =3Di586"; fi) endif =20 ifdef CONFIG_M686 -CFLAGS +=3D -march=3Di686 +CFLAGS +=3D $(shell if $(CC) -march=3Dpentium2 -S -o /dev/null -xc /dev/nu= ll >/dev/null 2>&1; then echo "-march=3Dpentium2"; else echo "-march=3Di686= "; fi) endif =20 ifdef CONFIG_MPENTIUMIII -CFLAGS +=3D -march=3Di686 +CFLAGS +=3D $(shell if $(CC) -march=3Dpentium3 -S -o /dev/null -xc /dev/nu= ll >/dev/null 2>&1; then echo "-march=3Dpentium3"; else echo "-march=3Di686= "; fi) endif =20 ifdef CONFIG_MPENTIUM4 -CFLAGS +=3D -march=3Di686 +CFLAGS +=3D $(shell if $(CC) -march=3Dpentium4 -S -o /dev/null -xc /dev/nu= ll >/dev/null 2>&1; then echo "-march=3Dpentium4"; else echo "-march=3Di686= "; fi) endif =20 ifdef CONFIG_MK6 @@ -63,7 +63,7 @@ endif =20 ifdef CONFIG_MK7 -CFLAGS +=3D -march=3Di686 -malign-functions=3D4=20 +CFLAGS +=3D $(shell if $(CC) -march=3Dathlon -S -o /dev/null -xc /dev/null= >/dev/null 2>&1; then echo "-march=3Dathlon"; else echo "-march=3Di686 -ma= lign-functions=3D4"; fi) endif =20 ifdef CONFIG_MCRUSOE --=-3agiF5hh511wQNrrjvSG-- From owner-linux-xfs@oss.sgi.com Thu Oct 17 02:13:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 02:13:40 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H9DYtG018958 for ; Thu, 17 Oct 2002 02:13:34 -0700 Received: from apps.cwi.nl (apps.cwi.nl [192.16.191.34]) by hera.cwi.nl with ESMTP id LAA14748 for ; Thu, 17 Oct 2002 11:13:25 +0200 (MEST) From: Andries.Brouwer@cwi.nl Received: by apps.cwi.nl id g9H9DP210769; Thu, 17 Oct 2002 11:13:25 +0200 (MEST) Date: Thu, 17 Oct 2002 11:13:25 +0200 (MEST) Message-Id: To: Andries.Brouwer@cwi.nl, ak@suse.de, nathans@sgi.com Subject: Re: Is there something special I need to do? Cc: austin@coremetrics.com, linux-xfs@oss.sgi.com, lord@sgi.com, sandeen@sgi.com X-archive-position: 1064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Andries.Brouwer@cwi.nl Precedence: bulk X-list: linux-xfs >> That's because whole disks are not in /proc/partitions. > They are, the problem is mount explicitly skips them > Why mount does this, I have no idea There is no very good reason. Under Linux one customarily partitions disks, but there is no need to do so. Under BSD I see whole-disk filesystems more often. As soon as you file a bug report explaining the skipping whole disks as possible mountable objects is bad I'll remove the test. Andries From owner-linux-xfs@oss.sgi.com Thu Oct 17 02:14:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 02:14:08 -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 g9H9E5tG019118 for ; Thu, 17 Oct 2002 02:14:05 -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 g9H9E1fU059589; Thu, 17 Oct 2002 11:14:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20021017111146.039a8490@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Oct 2002 11:12:51 +0200 To: Eric Sandeen , Austin Gonyou From: Seth Mos Subject: Re: Is there something special I need to do? Cc: Stephen Lord , In-Reply-To: References: <1034817011.7264.119.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1065 X-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 21:04 16-10-2002 -0500, Eric Sandeen wrote: >Dunno, I tested a whole disk with xfs and ext2, and neither could mount >by label. The answer was already given, complete devices don't show up in /proc/partitions so the disk will not get scanned for mount by label. Just make one large partition. >-Eric > >On 16 Oct 2002, Austin Gonyou wrote: > > > On Wed, 2002-10-16 at 19:49, Stephen Lord wrote: > > > ... > > > > > I then added LABEL=name /mountpoint xfs defaults 1 2 and I can't > > > mount > > > > > LABEL=name. Did I do something wrong in that scenario? > > > > > > > > as a side note to this, I didn't make any partitions, I'm just using > > > the > > > > whole disk. I dunno if that makes a difference but thought I'd ask. > > > > > > Not sure, the mount command scans everything which appears in > > > /proc/partitions if your filesystem is in there it should work, > > > provided the items I just mentioned are taken care of. > > > > Gotcha. I'll check it out. :) > > > > > > > Steve > > > > > > > > -- > > Austin Gonyou > > Coremetrics, Inc. > > -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Oct 17 02:39:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 02:39:09 -0700 (PDT) Received: from sisko.scot.redhat.com (pc-62-31-74-29-ed.blueyonder.co.uk [62.31.74.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H9d5tG023009 for ; Thu, 17 Oct 2002 02:39:05 -0700 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id g9H9cph03599; Thu, 17 Oct 2002 10:38:51 +0100 Date: Thu, 17 Oct 2002 10:38:51 +0100 From: "Stephen C. Tweedie" To: Andi Kleen Cc: "Stephen C. Tweedie" , linux-xfs@oss.sgi.com Subject: Re: to compare journalised file systems Message-ID: <20021017103851.A3277@redhat.com> References: <20021016203853.GH27982@plato.local.lan> <20021016214759.GI27982@plato.local.lan> <20021017000107.A21179@wotan.suse.de> <20021016230948.B524@redhat.com> <20021017001549.A27231@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021017001549.A27231@wotan.suse.de>; from ak@suse.de on Thu, Oct 17, 2002 at 12:15:49AM +0200 X-archive-position: 1066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Hi, On Thu, Oct 17, 2002 at 12:15:49AM +0200, Andi Kleen wrote: > > lseek is ignored on O_APPEND files --- the write always re-seeks to > > EOF. pwrite goes down that same code path too so it also gets the > > append enforced. In your testing were you testing real writes, or > > just the lseeks? > > I was testing a real write. Another hole is pwrite(). No, both work fine. The lseek only operates on the internal f_pos, it doesn't affect the file. The write does affect the file but it re-seeks back to EOF, so the write always appends. Tested on both 2.4 and 2.5. > #include > #include > > main(int ac, char **av) > { > int fd = open(av[1], O_APPEND|O_WRONLY); > > if (lseek(fd, 100, SEEK_SET) < 0) perror("expected lseek error"); > if (write(fd, "1", 1) < 0) perror("expected write error"); > else printf("write succeeded\n"); > > } > % gcc -o tseek tseek.c > % dd if=/dev/zero of=/tmp/TEST bs=1k count=10 > % su > # chattr +a /tmp/TEST > % ./tseek /tmp/TEST > write succeeded Fine. That's correct behaviour. Do an "ls -l /tmp/TEST" afterwards and you'll see that it got exactly one byte longer as a result of the one-byte write. The write was an append despite the lseek. This is the behaviour required by SingleUnix. Internally, O_APPEND is enforced in generic_file_write, not by lseek. (Any filesystem which overrides generic_file_write needs to do the appropriate logic itself.) Cheers, Stephen From owner-linux-xfs@oss.sgi.com Thu Oct 17 06:38:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 06:39:03 -0700 (PDT) Received: from siufuxsun03.unifr.ch (siufuxsun03.unifr.ch [134.21.13.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HDcptG018078 for ; Thu, 17 Oct 2002 06:38:59 -0700 Received: from siufuxsun00.unifr.ch ([134.21.13.50] helo=siufuxsun04.unifr.ch) by siufuxsun03.unifr.ch with esmtp (Exim 3.22 #1) id 182ArF-0005RG-00 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 15:38:37 +0200 Received: from siufuxpc04.unifr.ch ([134.21.13.104]) by siufuxsun04.unifr.ch with esmtp (Exim 3.22 #4) id 182ArE-00022B-00 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 15:38:36 +0200 Received: from zahno (helo=siufuxpc04.unifr.ch) by siufuxpc04.unifr.ch with local-esmtp (Exim 3.22 #1) id 182ArE-0001nI-00 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 15:38:36 +0200 X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 To: linux-xfs@oss.sgi.com Subject: Compiling custom redhat xfs kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Oct 2002 15:38:36 +0200 From: Hans-Peter Zahno Message-Id: X-archive-position: 1067 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hans-peter.zahno@unifr.ch Precedence: bulk X-list: linux-xfs Hello, I'm using the contribud XFS-Kernel for redhat: 2.4.18-4SGI_XFS_1.1smp on a Dell PE2550 I'm happy with it and it seems to work well. Now I need to recompile it with the following config parameter set to yes: CONFIG_SCSI_MULTI_LUN=y When running the 'make dep' I get the following error: .. make[4]: Entering directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' /usr/src/linux-2.4.18-4SGI_XFS_1.1/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.18-4SGI_XFS_1.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -Wno-unused -pipe -mpreferred-stack-boundary=2 -march=i686 -- br.c br_device.c br_fdb.c br_forward.c br_if.c br_input.c br_ioctl.c br_netfilter.c br_notify.c br_private.h br_private_stp.h br_private_timer.h br_stp_bpdu.c br_stp.c br_stp_if.c br_stp_timer.c > .depend make[4]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' make -C core fastdep make: Entering an unknown directory make: *** core: No such file or directory. Stop. make: Leaving an unknown directory make[3]: *** [_sfdep_core] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net' make[1]: *** [_sfdep_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1' make: *** [dep-files] Error 2 Do you have any idea what is missing or is wrong? Thanks for any hint. Regards Hans-Peter Zahno From owner-linux-xfs@oss.sgi.com Thu Oct 17 07:52:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 07:52:38 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9HEqXtG026343 for ; Thu, 17 Oct 2002 07:52:33 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9HEqXnT026341 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 07:52:33 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9HEqVtI026323 for ; Thu, 17 Oct 2002 07:52:31 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9HEepsC025391; Thu, 17 Oct 2002 07:40:51 -0700 Date: Thu, 17 Oct 2002 07:40:51 -0700 Message-Id: <200210171440.g9HEepsC025391@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 183] warings when compiling kernel X-Bugzilla-Reason: AssignedTo X-archive-position: 1068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=183 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From sandeen@sgi.com 2002-10-17 07:40 ------- On Thu, 2002-10-17 at 03:40, Ajay Ramaswamy wrote: > Eric, > > 0. here is the patch the bugzilla one is wrapped and unusable > > 1. The warnings are there without the patch. > > 2. The warnings are there in other parts of the kernel too. > > > Thanks & regards > Ajay Ok, I'm going to close this as invalid (i.e. notabug) since this is not unique to XFS code, and we really aren't in the business of fixing non-xfs bugs in Red Hat's kernel etc. It might be a good idea to file this bug with either Red Hat or Marcello... If I'm missing something here and the stock Red Hat kernel compiles without warnings, please re-open this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 17 09:59:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 09:59:17 -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 g9HGxFtG005748 for ; Thu, 17 Oct 2002 09:59:15 -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 LAA17890 for ; Thu, 17 Oct 2002 11:59:09 -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 LAA67919; Thu, 17 Oct 2002 11:59:08 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9HGtYQ01796; Thu, 17 Oct 2002 11:55:34 -0500 Message-Id: <200210171655.g9HGtYQ01796@stout.americas.sgi.com> Date: Thu, 17 Oct 2002 11:55:34 -0500 Subject: TAKE 870303 - problem with minimal acls on linux X-archive-position: 1069 X-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 the heavy acl users out there could test this a bit, it would be much appreciated. Avoid creating attrs for acls which can be stored in the standard permission bits, and remove existing attrs if acls are reduced to standard permissions. Date: Thu Oct 17 09:57:49 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:130256a linux/fs/xfs/xfs_acl.c - 1.34 From owner-linux-xfs@oss.sgi.com Thu Oct 17 11:11:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 11:11:16 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HIBDtG029053 for ; Thu, 17 Oct 2002 11:11:13 -0700 Received: (qmail 30411 invoked by uid 500); 17 Oct 2002 18:10:45 -0000 Subject: Re: Is there something special I need to do? From: Austin Gonyou To: Eric Sandeen Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TBSj6Tqt+wyuSyUC987l" Organization: Coremetrics, Inc. Message-Id: <1034878244.30299.0.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 17 Oct 2002 13:10:45 -0500 X-archive-position: 1070 X-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 --=-TBSj6Tqt+wyuSyUC987l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-10-16 at 21:04, Eric Sandeen wrote: > Dunno, I tested a whole disk with xfs and ext2, and neither could > mount > by label. Good deal then. :) > -Eric --=20 Austin Gonyou Coremetrics, Inc. --=-TBSj6Tqt+wyuSyUC987l 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 iD8DBQA9rv0k94g6ZVmFMoIRAtFLAJ9DhEGV1oddcYvmTkQyx9oM0NizLQCg6Eq3 QY9G5G3Uexd9Pa/S8G7wmNI= =Y3jC -----END PGP SIGNATURE----- --=-TBSj6Tqt+wyuSyUC987l-- From owner-linux-xfs@oss.sgi.com Thu Oct 17 11:12:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 11:12:43 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HICetG029371 for ; Thu, 17 Oct 2002 11:12:40 -0700 Received: (qmail 30428 invoked by uid 500); 17 Oct 2002 18:12:00 -0000 Subject: Re: Compiling custom redhat xfs kernel From: Austin Gonyou To: Hans-Peter Zahno Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-I7APMuvnfvXRpFl7J+W/" Organization: Coremetrics, Inc. Message-Id: <1034878319.30299.2.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 17 Oct 2002 13:12:00 -0500 X-archive-position: 1071 X-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 --=-I7APMuvnfvXRpFl7J+W/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd say make mrproper, make config, set all your bits you need, then make dep. It sounds like somethings not working, and it could be a default config issue. On Thu, 2002-10-17 at 08:38, Hans-Peter Zahno wrote: > Hello, >=20 > I'm using the contribud XFS-Kernel for redhat: > 2.4.18-4SGI_XFS_1.1smp on a Dell PE2550 >=20 > I'm happy with it and it seems to work well. Now I need > to recompile it with the following config parameter set to yes: > CONFIG_SCSI_MULTI_LUN=3Dy >=20 > When running the 'make dep' I get the following error: > .. > make[4]: Entering directory > `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' > /usr/src/linux-2.4.18-4SGI_XFS_1.1/scripts/mkdep -D__KERNEL__ > -I/usr/src/linux-2.4.18-4SGI_XFS_1.1/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing > -fno-common -Wno-unused -pipe -mpreferred-stack-boundary=3D2 > -march=3Di686 -- br.c br_device.c br_fdb.c br_forward.c br_if.c > br_input.c br_ioctl.c br_netfilter.c br_notify.c br_private.h > br_private_stp.h br_private_timer.h br_stp_bpdu.c br_stp.c br_stp_if.c > br_stp_timer.c > .depend >=20 > make[4]: Leaving directory > `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' > make -C core fastdep > make: Entering an unknown directory > make: *** core: No such file or directory. Stop. > make: Leaving an unknown directory > make[3]: *** [_sfdep_core] Error 2 > make[3]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net' > make[2]: *** [fastdep] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net' > make[1]: *** [_sfdep_net] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1' > make: *** [dep-files] Error 2 >=20 > Do you have any idea what is missing or is wrong? >=20 > Thanks for any hint. > Regards > Hans-Peter Zahno --=20 Austin Gonyou Coremetrics, Inc. --=-I7APMuvnfvXRpFl7J+W/ 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 iD8DBQA9rv1v94g6ZVmFMoIRAs3jAKCLqpirwzX0bO+UG5Wo8X6TXiY1dwCggFEc ym5g/3KfHeWkS6VMM8lOyUk= =enmH -----END PGP SIGNATURE----- --=-I7APMuvnfvXRpFl7J+W/-- From owner-linux-xfs@oss.sgi.com Thu Oct 17 13:52:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 13:52:40 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9HKqZtG012681 for ; Thu, 17 Oct 2002 13:52:35 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9HKqYUv012680 for linux-xfs@oss.sgi.com; Thu, 17 Oct 2002 13:52:34 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9HKqXtI012663 for ; Thu, 17 Oct 2002 13:52:33 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9HKXYYk011215; Thu, 17 Oct 2002 13:33:34 -0700 Date: Thu, 17 Oct 2002 13:33:34 -0700 Message-Id: <200210172033.g9HKXYYk011215@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 182] Hitting the BUG() in filemap.c:843 (in unlock_page()) X-Bugzilla-Reason: AssignedTo X-archive-position: 1072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=182 ------- Additional Comments From sandeen@sgi.com 2002-10-17 13:33 ------- More info from Luben: Here's is our setup -- more detailed: 2.4.19 stock, ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19/xfs-2.4.19-all-i386.bz2 from 2002-09-27, 4:22 UTC. Using the LVM from the stock kernel. The lvm commands are the ones from 1.1-rc2 and you may see some not understood ioctls, but we've ignored them. This is /etc/raidtab: raiddev /dev/md0 raid-level 5 nr-raid-disks 4 nr-spare-disks 0 persistent-superblock 1 parity-algorithm left-symmetric chunk-size 64 device /dev/sda raid-disk 0 device /dev/sdb raid-disk 1 device /dev/sdc raid-disk 2 device /dev/sdd raid-disk 3 ------------------------------------------------------- This is the script to create the vg/lv device: #!/bin/bash . ./DEVICE_NAMES DEVICE=/dev/md0 pvcreate -ffy $DEVICE vgcreate $VG -s32M -p255 -l256 $DEVICE lvcreate -L1G -n${LV} $VG -------------------------------------------------------- This is the script to mount the device: #!/bin/bash . ./DEVICE_NAMES # FSPROG=mke2fs # FSTYPE=ext2 FSPROG="mkfs.xfs -f" FSTYPE=xfs MOUNTP=/mnt/disk echo Unmounting... umount ${MOUNTP} echo Sleeping for 2... sleep 2 echo Doing work... ${FSPROG} /dev/${VG}/${LV} echo "sleeping ..." sleep 3 mount -t ${FSTYPE} -onoatime,nodiratime,usrquota,grpquota /dev/${VG}/${LV} ${MOUNTP} ---------------------------------------------- And this is DEVICE_NAMES file: # VG= the name of the vol group; LV= the name of the log. vol. VG=vg0 LV=lv0 ---------------------------------------------- The kernel has NO quota compiled in, only the one from xfs and it has HIGHMEM enabled to 4 GB. Try this set up, you should get the same bug and the same stack trace. In the mean time I'll the the latest CVS trunk, which is what you tried I think. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 17 16:17:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 16:17:30 -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 g9HNHMtG025769 for ; Thu, 17 Oct 2002 16:17:23 -0700 Received: (qmail 15138 invoked from network); 17 Oct 2002 23:17:21 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 17 Oct 2002 23:17:21 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C753E300B3D; Fri, 18 Oct 2002 09:17:19 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id A6839108F for ; Fri, 18 Oct 2002 09:17:19 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: Compiling custom redhat xfs kernel In-reply-to: Your message of "Thu, 17 Oct 2002 15:38:36 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Oct 2002 09:17:14 +1000 Message-ID: <20138.1034896634@ocs3.intra.ocs.com.au> X-archive-position: 1073 X-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 Thu, 17 Oct 2002 15:38:36 +0200, Hans-Peter Zahno wrote: >I'm using the contribud XFS-Kernel for redhat: >2.4.18-4SGI_XFS_1.1smp on a Dell PE2550 > >I'm happy with it and it seems to work well. Now I need >to recompile it with the following config parameter set to yes: >CONFIG_SCSI_MULTI_LUN=y > >When running the 'make dep' I get the following error: >.. >make[4]: Entering directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' >/usr/src/linux-2.4.18-4SGI_XFS_1.1/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.18-4SGI_XFS_1.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -Wno-unused -pipe -mpreferred-stack-boundary=2 -march=i686 -- br.c br_device.c br_fdb.c br_forward.c br_if.c br_input.c br_ioctl.c br_netfilter.c br_notify.c br_private.h br_private_stp.h br_private_timer.h br_stp_bpdu.c br_stp.c br_stp_if.c br_stp_timer.c > .depend >make[4]: Leaving directory `/usr/src/linux-2.4.18-4SGI_XFS_1.1/net/bridge' >make -C core fastdep >make: Entering an unknown directory >make: *** core: No such file or directory. Stop. You have deleted the net/core directory from your kernel tree. I bet that you have a script that finds entries called 'core' and deletes them without first checking if they are files or directories. Linus will not change the name of this directory, he expects scripts that delete core files to get it right and not delete directories. From owner-linux-xfs@oss.sgi.com Thu Oct 17 16:29:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 16:29:54 -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 g9HNTptG027030 for ; Thu, 17 Oct 2002 16:29:51 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54AB62FA71 for ; Thu, 17 Oct 2002 16:29:51 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 8BEC52FA71 for ; Thu, 17 Oct 2002 16:29:50 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 2AE673438 for ; Thu, 17 Oct 2002 16:29:40 -0700 (PDT) Subject: Re: Gaurenteed file write?? From: Florin Andrei To: xfs mailing list In-Reply-To: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> References: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Oct 2002 16:29:40 -0700 Message-Id: <1034897380.20205.26.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1074 X-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-15 at 11:03, Greg Freemyer wrote: > > For this specific file and shell script, what extra logic can I add that would give me the highest likelihood of a successful disk write. > > i.e. Would sync; sync; increase my odds of always successfully writing this file out? I always add sync at the end of critical scripts. Sometimes i insert supplemental "sync"s inside the script, after important steps are completed. But be aware that, on extremely busy machines with large amounts of memory, sync can trigger a write storm on your disk array that might hurt performance. It's only for a short while, but sometimes it matters. And you don't really need sync in all your scripts. Perhaps in only 5..10% of them. -- Florin Andrei Writing a book on wireless security is like writing a book on safe skydiving. From owner-linux-xfs@oss.sgi.com Thu Oct 17 17:15:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 17:16:00 -0700 (PDT) Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9I0FwtG032241 for ; Thu, 17 Oct 2002 17:15:58 -0700 Received: from nwourms@netscape.net by imo-d08.mx.aol.com (mail_out_v34.13.) id 4.2c.5e625d2 (16227) for ; Thu, 17 Oct 2002 20:15:48 -0400 (EDT) Received: from netscape.net ([130.127.122.186]) by air-in02.mx.aol.com (v89.12) with ESMTP id MAILININ23-1017201548; Thu, 17 Oct 2002 20:15:48 -0400 Message-ID: <3DAF51A1.2020304@netscape.net> Date: Thu, 17 Oct 2002 20:11:13 -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 Subject: XFS ACLs + Ted's EXT2/EXT3 ACLs in 2.5.43? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) X-archive-position: 1075 X-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'm probably barking up the wrong tree, but I was wondering if there were any issues that would prevent Ted's ext ACLs from co-existing with XFS's ACLs. My base kernel is 2.5.43 checked out from the XFS cvs tree as of this afternoon. Ted's patches went in pretty cleanly [required cleaning the fs/config.{help|in} for dupes] except for one part in include/linux/fs.h: He has assigned the bitvector (1<<16) to the macro MS_POSIXACL whereas you have assigned an explicit value. Will it cause problems for XFS's ACLs if I replace the explicit value with the bitvector? Or is this just 32bit vs 64bit stuff I need not worry about (since I'm on ia32)? Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Thu Oct 17 17:30:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Oct 2002 17:30:49 -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 g9I0UjtG001625 for ; Thu, 17 Oct 2002 17:30:45 -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 RAA03494 for ; Thu, 17 Oct 2002 17:30:43 -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 KAA01061; Fri, 18 Oct 2002 10:29:02 +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 g9I0SNe4001646; Fri, 18 Oct 2002 10:28:23 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g9I0SMkY001644; Fri, 18 Oct 2002 10:28:22 +1000 Date: Fri, 18 Oct 2002 10:28:22 +1000 From: Nathan Scott To: Nicholas Wourms Cc: linux-xfs Subject: Re: XFS ACLs + Ted's EXT2/EXT3 ACLs in 2.5.43? Message-ID: <20021018002822.GC531@frodo> References: <3DAF51A1.2020304@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAF51A1.2020304@netscape.net> User-Agent: Mutt/1.4i X-archive-position: 1076 X-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 Thu, Oct 17, 2002 at 08:11:13PM -0400, Nicholas Wourms wrote: > Hi, hello. > I'm probably barking up the wrong tree, but I was wondering > if there were any issues that would prevent Ted's ext ACLs [ Giving credit where its due - Andreas Gruenbacher implemented all of this code (afaik) ] > from co-existing with XFS's ACLs. My base kernel is 2.5.43 No there are no issues. The current implementations were designed to coexist and much work was done in conjunction. > checked out from the XFS cvs tree as of this afternoon. > Ted's patches went in pretty cleanly [required cleaning the > fs/config.{help|in} for dupes] except for one part in > include/linux/fs.h: > > He has assigned the bitvector (1<<16) to the macro > MS_POSIXACL whereas you have assigned an explicit value. Its the same value though, right? ... (gdb) p 1 << 16 $1 = 65536 65536 is consistent with the other MS_* flags declarations. > Will it cause problems for XFS's ACLs if I replace the > explicit value with the bitvector? nope. > Or is this just 32bit vs > 64bit stuff I need not worry about (since I'm on ia32)? no, thats not an issue here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 18 06:11:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 06:11:07 -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 g9IDB1tG004478 for ; Fri, 18 Oct 2002 06:11:01 -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 IAA18653; Fri, 18 Oct 2002 08:10:55 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 182Wtz-0006Nz-00; Fri, 18 Oct 2002 08:10:55 -0500 Date: Fri, 18 Oct 2002 08:10:55 -0500 From: Nathan Straz To: Greg Freemyer Cc: xfs mailing list Subject: Re: Gaurenteed file write?? Message-ID: <20021018131055.GA23684@sgi.com> Mail-Followup-To: Greg Freemyer , xfs mailing list References: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015180506.NXFR22240.imf13bis.bellsouth.net@Mother2> User-Agent: Mutt/1.4i X-archive-position: 1077 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Oct 15, 2002 at 02:03:21PM -0400, Greg Freemyer wrote: > I have an iteration counter that I update every night. > > echo $ITERATION > /backup/iteration > > Recently this file was reset to 0. You might want to think about storing $ITERNATION as part of a file name instead of in a file. That way $ITERATION is part of a journal transaction. That might give you better results. -- 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 18 06:34:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 06:34:45 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm6.tiscalinet.be [212.35.2.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IDYftG006801 for ; Fri, 18 Oct 2002 06:34:41 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscalinet) id 182XGx-0001wf-00 for ; Fri, 18 Oct 2002 15:34:39 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Fri, 18 Oct 2002 15:30:53 +0100 Date: Fri, 18 Oct 2002 16:30:53 +0200 Message-ID: <3DA56CAE0000313D@ocpmta8.be.tiscali.com> From: jsoe0708@tiscali.be Subject: XFS (CVS release) problem to compile on hppa To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs Hi all, For kernel 2.4.19 I have to go to cvs release of xfs;-) So I build a 'patch' against vanilla k-2.4.19 and apply it against k-2.4.19-pa22. (Just met a small problem of conflict) But the build failled because: "../xfs_bmap_btree.h:661:35: "0" may not appear in macro parameter list" and in this header I found: "... #else ... #define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ xfs_bmbt_set_allf(r, 0, b, c, v) #endif ... " just above there are: void xfs_bmbt_disk_set_allf( xfs_bmbt_rec_t *r, xfs_fileoff_t o, xfs_fsblock_t b, xfs_filblks_t c, xfs_exntst_t v); What do you think? Thanks in advance for advise, Joel PS: on hppa, linux kernel have to be build with gcc > 3.0.4 From owner-linux-xfs@oss.sgi.com Fri Oct 18 06:41:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 06:41: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 g9IDfatG007794 for ; Fri, 18 Oct 2002 06:41:36 -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 IAA66151; Fri, 18 Oct 2002 08:41:31 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-1.corp.sgi.com [134.15.64.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA29802; Fri, 18 Oct 2002 08:41:28 -0500 (CDT) Subject: Re: XFS (CVS release) problem to compile on hppa From: Stephen Lord To: jsoe0708@tiscali.be Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DA56CAE0000313D@ocpmta8.be.tiscali.com> References: <3DA56CAE0000313D@ocpmta8.be.tiscali.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Oct 2002 08:37:25 -0500 Message-Id: <1034948248.1421.25.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1079 X-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-18 at 09:30, jsoe0708@tiscali.be wrote: > But the build failled because: > "../xfs_bmap_btree.h:661:35: "0" may not appear in macro parameter list" > > and in this header I found: > "... > #else > ... > #define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ > xfs_bmbt_set_allf(r, 0, b, c, v) > #endif > ... > " This should be fixed in the latest cvs code - if it is not our cvs updates have stalled again. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 18 07:01:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 07:01:30 -0700 (PDT) Received: from imf14bis.bellsouth.net (mail014.mail.bellsouth.net [205.152.58.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IE1OtG009897 for ; Fri, 18 Oct 2002 07:01:25 -0700 Received: from Mother2 ([67.35.80.128]) by imf14bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021018140302.GQCA1223.imf14bis.bellsouth.net@Mother2>; Fri, 18 Oct 2002 10:03:02 -0400 Date: Fri, 18 Oct 2002 10:01:16 -0400 From: Greg Freemyer Subject: re[2]: Gaurenteed file write?? To: Nathan Straz cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021018140302.GQCA1223.imf14bis.bellsouth.net@Mother2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9IE1PtG009902 X-archive-position: 1080 X-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 >> On Tue, Oct 15, 2002 at 02:03:21PM -0400, Greg Freemyer wrote: >> > I have an iteration counter that I update every night. >> > >> > echo $ITERATION > /backup/iteration >> > >> > Recently this file was reset to 0. >> You might want to think about storing $ITERNATION as part of a file >> name instead of in a file. That way $ITERATION is part of a journal >> transaction. That might give you better results. >> -- >> Nate Straz nstraz@sgi.com Nate, Thanks for that excellent advice. Greg From owner-linux-xfs@oss.sgi.com Fri Oct 18 07:01:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 07:01:53 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm2.tiscalinet.be [212.35.2.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IE1otG010067 for ; Fri, 18 Oct 2002 07:01:51 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscalinet) id 182XhD-0000PX-00; Fri, 18 Oct 2002 16:01:47 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Fri, 18 Oct 2002 15:57:39 +0100 Date: Fri, 18 Oct 2002 16:57:39 +0200 Message-ID: <3DA56CAE00003170@ocpmta8.be.tiscali.com> In-Reply-To: <1034948248.1421.25.camel@laptop.americas.sgi.com> From: jsoe0708@tiscali.be Subject: Re: XFS (CVS release) problem to compile on hppa To: "Stephen Lord" Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs Hello Steve, > >> But the build failled because: >> "../xfs_bmap_btree.h:661:35: "0" may not appear in macro parameter list" >> >> and in this header I found: >> "... >> #else >> ... >> #define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ >> xfs_bmbt_set_allf(r, 0, b, c, v) >> #endif >> ... >> " > >This should be fixed in the latest cvs code - if it is not our >cvs updates have stalled again. > You have right (I am so confused. I do make a mistake somewhere but do not see which?) Thanks again for so quick answer, Joel From owner-linux-xfs@oss.sgi.com Fri Oct 18 09:22:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 09:22:40 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IGMctG022225 for ; Fri, 18 Oct 2002 09:22:38 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IGMcrh022224 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 09:22:38 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IGMatI022210 for ; Fri, 18 Oct 2002 09:22:36 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IGD96S021571; Fri, 18 Oct 2002 09:13:09 -0700 Date: Fri, 18 Oct 2002 09:13:09 -0700 Message-Id: <200210181613.g9IGD96S021571@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] New: xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1082 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 Summary: xfs_force_shutdown called on lvm-snapshot Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: sgi@debian.franken.de I downloaded a kernel from cvs today at round about 12:00 +0200 o'clock. Then I applied lvm and lvm-snapshot-patches from the 1.0.5 lvm release. I also applied lm_sensor_patches, but I think they are not the probblem. When I tried to backup my system from 3 snapshots I got the following log-message: Oct 18 15:52:51 boss kernel: Ending clean XFS mount for filesystem: lvm(58,4) Oct 18 15:53:01 boss kernel: XFS mounting filesystem lvm(58,3) Oct 18 15:53:01 boss kernel: Ending clean XFS mount for filesystem: lvm(58,3) Oct 18 15:53:07 boss kernel: XFS mounting filesystem lvm(58,2) Oct 18 15:53:08 boss kernel: Ending clean XFS mount for filesystem: lvm(58,2) This was when I mounted my snapshots. Oct 18 15:57:42 boss kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/master/var-snap Oct 18 15:57:42 boss last message repeated 7 times Oct 18 15:57:42 boss kernel: I/O error in filesystem ("lvm(58,3)") meta-data dev 0x3a03 block 0x3013c4^I ("xlog_iodo ne") error 5 buf count 32768 Oct 18 15:57:42 boss kernel: xfs_force_shutdown(lvm(58,3),0x2) called from line 949 of file xfs_log.c. Return addre ss = 0xc01fbd9d Oct 18 15:57:42 boss kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,3) Oct 18 15:57:42 boss kernel: Please umount the filesystem, and rectify the problem(s) And this was some minutes after, 58,3 is my /var-snapshot. Tar was backupping this area at this moment. I would suggest try to install a system on lvm with root-fs on lvm and /home and /var on seperate partitions (the best would be debian-woody). Then create snapshots and then try to backup them with tar or so. Trying to snapshot a seperated lv would perhaps not be a good idea to reproduce it because perhaps this bug depends on IO-activity on the source of the snapshot. A backtrace on every lvm - lvm_map: ll_rw_blk write for readonly LV /dev/master/var-snap could be interesting too. If you can reproduce this with lvm, It would be interesting to know if this happens with evms-ro-snapshots too. This could help to fix the problem too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 09:25:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 09:25:37 -0700 (PDT) Received: from wideangle.nameip.net (s210-221-75-248.thrunet.ne.kr [210.221.75.248]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IGPYtG022783 for ; Fri, 18 Oct 2002 09:25:35 -0700 Received: (qmail 5826 invoked by uid 500); 18 Oct 2002 16:25:29 -0000 Subject: #define PF_FSTRANS From: Seung-young Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1034958328.2032.13.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 19 Oct 2002 01:25:28 +0900 X-archive-position: 1083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: so1713@orgio.net Precedence: bulk X-list: linux-xfs Hello, For XFS 1.1, If I were to change in 'include/linux/sched.h' from; +#define PF_FSTRANS 0x00008000 /* inside a filesystem transaction */ to; +#define PF_FSTRANS 0x00080000 /* inside a filesystem transaction */ then, where else should I adjust to meet this change I made? Enlighten me, please. Thank you. -- We Make the Net Work From owner-linux-xfs@oss.sgi.com Fri Oct 18 09:29:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 09:29:40 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IGTbtG023522 for ; Fri, 18 Oct 2002 09:29:38 -0700 Received: (qmail 31422 invoked by uid 500); 18 Oct 2002 16:29:17 -0000 Subject: Qlogic 2300 and XFS From: Austin Gonyou To: linux-xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XD57f15NUqtuh84cMaqL" Organization: Coremetrics, Inc. Message-Id: <1034958557.31228.14.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 18 Oct 2002 11:29:17 -0500 X-archive-position: 1084 X-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 --=-XD57f15NUqtuh84cMaqL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Anyone here using Qlogic 2300Fs and XFS with an uptime of > 30 days on 5.38.x drivers or > 15 days on 6.0x drivers? TIA --=20 Austin Gonyou Coremetrics, Inc. --=-XD57f15NUqtuh84cMaqL 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 iD8DBQA9sDbd94g6ZVmFMoIRAhZtAKDiyGEWvj74YcCT7MMglpnIde80WACgxsGu Qx3RuDaQ28i65ti4b0wkSSo= =ooBQ -----END PGP SIGNATURE----- --=-XD57f15NUqtuh84cMaqL-- From owner-linux-xfs@oss.sgi.com Fri Oct 18 09:34:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 09:34:08 -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 g9IGY6tG024328 for ; Fri, 18 Oct 2002 09:34:06 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA41473; Fri, 18 Oct 2002 11:34:00 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-1.corp.sgi.com [134.15.64.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA63615; Fri, 18 Oct 2002 11:33:59 -0500 (CDT) Subject: Re: #define PF_FSTRANS From: Stephen Lord To: Seung-young Oh Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034958328.2032.13.camel@wideangle.nameip.net> References: <1034958328.2032.13.camel@wideangle.nameip.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Oct 2002 11:29:56 -0500 Message-Id: <1034958598.1061.38.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1085 X-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-18 at 11:25, Seung-young Oh wrote: > Hello, > For XFS 1.1, If I were to change in 'include/linux/sched.h' from; > > +#define PF_FSTRANS 0x00008000 /* inside a filesystem > transaction */ > > to; > > +#define PF_FSTRANS 0x00080000 /* inside a filesystem > transaction */ > > then, where else should I adjust to meet this change I made? > Enlighten me, please. Thank you. No other change would be needed. Steve From owner-linux-xfs@oss.sgi.com Fri Oct 18 09:37:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 09:37:11 -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 g9IGb9tG024982 for ; Fri, 18 Oct 2002 09:37:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA33995; Fri, 18 Oct 2002 11:36:58 -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 LAA71717; Fri, 18 Oct 2002 11:36:58 -0500 (CDT) Subject: Re: #define PF_FSTRANS From: Eric Sandeen To: Seung-young Oh Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034958328.2032.13.camel@wideangle.nameip.net> References: <1034958328.2032.13.camel@wideangle.nameip.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 18 Oct 2002 11:33:14 -0500 Message-Id: <1034958795.8482.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1086 X-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 You should not need to change anything else, just make sure all of the PF_* flag values are unique, and < 32 bits. What are you merging? :) -Eric On Fri, 2002-10-18 at 11:25, Seung-young Oh wrote: > Hello, > For XFS 1.1, If I were to change in 'include/linux/sched.h' from; > > +#define PF_FSTRANS 0x00008000 /* inside a filesystem > transaction */ > > to; > > +#define PF_FSTRANS 0x00080000 /* inside a filesystem > transaction */ > > then, where else should I adjust to meet this change I made? > Enlighten me, please. Thank you. > -- > We Make the Net Work > -- 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 18 10:19:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 10:19:22 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-25.uc.nombres.ttd.es [213.99.177.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IHJEtG028242 for ; Fri, 18 Oct 2002 10:19:16 -0700 Received: (qmail 7982 invoked by uid 1000); 18 Oct 2002 17:20:02 -0000 From: yoros@wanadoo.es Date: Fri, 18 Oct 2002 19:20:02 +0200 To: linux-xfs Subject: About BUG #180 Message-ID: <20021018172002.GA7770@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I posted BUG number 180 related to "xfsdump" and "-e" option. It was that xfsdump didn't exclude files created after a level 0 dump but the attribute SGI_XFSDUMP_SKIP_FILE were added. Now I have more information about that situation. It happends that I executed xfsdump just after the find+attr commands. I think that xfsdump don't look at extended attributed that were not written to disk. I don't know nothing about the code of xfsdump or xfs. If anybody has any new information about this BUG, please send it to the list. Sorry for my english (i'm spanish). Have a nice day, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9sELBWIvihXTx06wRAqqeAJ9QUxUJTV7ara9Y5UUjhQIyOwxsAwCgv91D 1zjttqxp1oeBdR8QZwOmyvU= =Gqbz -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-linux-xfs@oss.sgi.com Fri Oct 18 10:24:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 10:24:35 -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 g9IHOTtG028883 for ; Fri, 18 Oct 2002 10:24:29 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA62306; Fri, 18 Oct 2002 12:24:23 -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 MAA07220; Fri, 18 Oct 2002 12:24:23 -0500 (CDT) Subject: Re: About BUG #180 From: Eric Sandeen To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021018172002.GA7770@morpheus.matrix.com> References: <20021018172002.GA7770@morpheus.matrix.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 18 Oct 2002 12:20:40 -0500 Message-Id: <1034961640.8948.31.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 g9IHOUtG028896 X-archive-position: 1088 X-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 Thanks for the extra info - can you add this to the bug entry in bugzilla as well? (trying to train our user base to use bugzilla a bit more.) :) Thanks, -Eric On Fri, 2002-10-18 at 12:20, yoros@wanadoo.es wrote: > > Hi, > > I posted BUG number 180 related to "xfsdump" and "-e" option. It was > that xfsdump didn't exclude files created after a level 0 dump but the > attribute SGI_XFSDUMP_SKIP_FILE were added. > > Now I have more information about that situation. It happends that I > executed xfsdump just after the find+attr commands. I think that xfsdump > don't look at extended attributed that were not written to disk. I don't > know nothing about the code of xfsdump or xfs. > > If anybody has any new information about this BUG, please send it to the > list. > > Sorry for my english (i'm spanish). Have a nice day, > > Pedro > > -- > Pedro Martinez Juli > \ yoros@terra.es > )| yoros@wanadoo.es > / http://yoros.cjb.net > Socio HispaLinux #311 > Usuario Linux #275438 - http://counter.li.org > GnuPG public information: pub 1024D/74F1D3AC > Key fingerprint = 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC -- 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 18 10:52:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 10:52:40 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IHqctG031872 for ; Fri, 18 Oct 2002 10:52:38 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IHqcAY031871 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 10:52:38 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IHqatG031857 for ; Fri, 18 Oct 2002 10:52:36 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IHg7wQ030740; Fri, 18 Oct 2002 10:42:07 -0700 Date: Fri, 18 Oct 2002 10:42:07 -0700 Message-Id: <200210181742.g9IHg7wQ030740@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 180] xfsdump is wrong with -e and files created since last dump X-Bugzilla-Reason: AssignedTo X-archive-position: 1089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=180 ------- Additional Comments From yoros@wanadoo.es 2002-10-18 10:42 ------- Created an attachment (id=40) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=40&action=view) New extra information abot the BUG There's a mail explaining the new info I have about the work of xfsdump... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 10:59:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 10:59:07 -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 g9IHx5tG032762 for ; Fri, 18 Oct 2002 10:59:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA48420; Fri, 18 Oct 2002 12:58:59 -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 MAA69949; Fri, 18 Oct 2002 12:58:59 -0500 (CDT) Subject: Re: About BUG #180 From: Eric Sandeen To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021018172002.GA7770@morpheus.matrix.com> References: <20021018172002.GA7770@morpheus.matrix.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 18 Oct 2002 12:55:15 -0500 Message-Id: <1034963715.8442.45.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 g9IHx6tG000307 X-archive-position: 1090 X-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 Pedro - so, are you saying that it fails immediately after you run find+attr, but it works if you wait for everything to get on-disk? -Eric On Fri, 2002-10-18 at 12:20, yoros@wanadoo.es wrote: > > Hi, > > I posted BUG number 180 related to "xfsdump" and "-e" option. It was > that xfsdump didn't exclude files created after a level 0 dump but the > attribute SGI_XFSDUMP_SKIP_FILE were added. > > Now I have more information about that situation. It happends that I > executed xfsdump just after the find+attr commands. I think that xfsdump > don't look at extended attributed that were not written to disk. I don't > know nothing about the code of xfsdump or xfs. > > If anybody has any new information about this BUG, please send it to the > list. > > Sorry for my english (i'm spanish). Have a nice day, > > Pedro > > -- > Pedro Martinez Juli > \ yoros@terra.es > )| yoros@wanadoo.es > / http://yoros.cjb.net > Socio HispaLinux #311 > Usuario Linux #275438 - http://counter.li.org > GnuPG public information: pub 1024D/74F1D3AC > Key fingerprint = 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC -- 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 18 11:12:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 11:12:11 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-25.uc.nombres.ttd.es [213.99.177.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IIC3tG001650 for ; Fri, 18 Oct 2002 11:12:05 -0700 Received: (qmail 8337 invoked by uid 1000); 18 Oct 2002 18:12:52 -0000 From: yoros@wanadoo.es Date: Fri, 18 Oct 2002 20:12:52 +0200 To: linux-xfs Subject: Re: About BUG #180 Message-ID: <20021018181252.GA8295@morpheus.matrix.com> References: <20021018172002.GA7770@morpheus.matrix.com> <1034963715.8442.45.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <1034963715.8442.45.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 18, 2002 at 12:55:15PM -0500, Eric Sandeen wrote: > Pedro - so, are you saying that it fails immediately after you run > find+attr, but it works if you wait for everything to get on-disk? I can't be 100% sure of it, but in a few experiences, the more I wait, the less marked files are selected. I tried to umount and mount again and it seems to work well. This two reasons makes me think that xfsdump don't show in the information that is in journal or something like it. Ah, I tried to run "sync; sync; sync;" after xfsdump but don't work. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9sE8jWIvihXTx06wRAk/WAJ9f8nMU7DvIMIav980CL+zDWpXBdwCgu70O JcY36N7OL28bskzNMRAs0co= =My/V -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs@oss.sgi.com Fri Oct 18 11:36:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 11:36:27 -0700 (PDT) Received: from wideangle.nameip.net (s210-221-75-248.thrunet.ne.kr [210.221.75.248]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IIaJtG003725 for ; Fri, 18 Oct 2002 11:36:20 -0700 Received: (qmail 9360 invoked by uid 500); 18 Oct 2002 18:36:13 -0000 Subject: Re: #define PF_FSTRANS From: Seung-young Oh To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1034958795.8482.24.camel@stout.americas.sgi.com> References: <1034958328.2032.13.camel@wideangle.nameip.net> <1034958795.8482.24.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=EUC-KR Organization: Message-Id: <1034966173.2032.21.camel@wideangle.nameip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 19 Oct 2002 03:36:13 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9IIaLtG003729 X-archive-position: 1092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: so1713@orgio.net Precedence: bulk X-list: linux-xfs Hello, I wanted to make XFS 1.1 version of the new RH 7.x kernel RPM based on the kernel RPM from RH7.3XFS1.1 installer; http://rhn.redhat.com/errata/RHSA-2002-205.html However, failed miserably... Any volunteer to save my day? Have a nice day, everyone. 2002-10-19 配 01:33, Eric Sandeen捞(啊) 靖: > You should not need to change anything else, just make sure all of the > PF_* flag values are unique, and < 32 bits. > > What are you merging? :) > > -Eric > > On Fri, 2002-10-18 at 11:25, Seung-young Oh wrote: > > Hello, > > For XFS 1.1, If I were to change in 'include/linux/sched.h' from; > > > > +#define PF_FSTRANS 0x00008000 /* inside a filesystem > > transaction */ > > > > to; > > > > +#define PF_FSTRANS 0x00080000 /* inside a filesystem > > transaction */ > > > > then, where else should I adjust to meet this change I made? > > Enlighten me, please. Thank you. > > -- > > We Make the Net Work > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 -- We Make the Net Work From owner-linux-xfs@oss.sgi.com Fri Oct 18 13:22:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 13:22:44 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IKMdtG012296 for ; Fri, 18 Oct 2002 13:22:39 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IKMdft012295 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 13:22:39 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IKMbtI012278 for ; Fri, 18 Oct 2002 13:22:37 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IK4e3W011248; Fri, 18 Oct 2002 13:04:40 -0700 Date: Fri, 18 Oct 2002 13:04:40 -0700 Message-Id: <200210182004.g9IK4e3W011248@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 180] xfsdump is wrong with -e and files created since last dump X-Bugzilla-Reason: AssignedTo X-archive-position: 1093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=180 ------- Additional Comments From sandeen@sgi.com 2002-10-18 13:04 ------- More info from Pedro: Now I have more information about that situation. It happends that I executed xfsdump just after the find+attr commands. I think that xfsdump don't look at extended attributed that were not written to disk. I can't be 100% sure of it, but in a few experiences, the more I wait, the less marked files are selected. I tried to umount and mount again and it seems to work well. This two reasons makes me think that xfsdump don't show in the information that is in journal or something like it. Ah, I tried to run "sync; sync; sync;" after xfsdump but don't work. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 14:51:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 14:52:03 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ILpttG018362 for ; Fri, 18 Oct 2002 14:51:58 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9ILpmf19274 for ; Fri, 18 Oct 2002 17:51:48 -0400 Message-ID: <3DB08276.E562BBF1@splentec.com> Date: Fri, 18 Oct 2002 17:51:50 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: No change: [Bug 182] New: Hitting the BUG() in filemap.c:843 (in unlock_page()) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1094 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Downloaded CVS version today (2002-10-18) at about 4:00 pm EDT. Hitting the same BUG() with the configuration as described in bug 182. Will give it a try... Eric? -- Luben From owner-linux-xfs@oss.sgi.com Fri Oct 18 15:15:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 15:16: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 g9IMFstG020304 for ; Fri, 18 Oct 2002 15:15:54 -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 PAA06735 for ; Fri, 18 Oct 2002 15:15: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 IAA10853; Sat, 19 Oct 2002 08:14:36 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA13444; Sat, 19 Oct 2002 08:14:36 +1000 (EST) Date: Sat, 19 Oct 2002 08:14:35 +1000 From: Nathan Scott To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: About BUG #180 Message-ID: <20021019081435.C312126@wobbly.melbourne.sgi.com> References: <20021018172002.GA7770@morpheus.matrix.com> <1034963715.8442.45.camel@stout.americas.sgi.com> <20021018181252.GA8295@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021018181252.GA8295@morpheus.matrix.com>; from yoros@wanadoo.es on Fri, Oct 18, 2002 at 08:12:52PM +0200 X-archive-position: 1095 X-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 Fri, Oct 18, 2002 at 08:12:52PM +0200, yoros@wanadoo.es wrote: > On Fri, Oct 18, 2002 at 12:55:15PM -0500, Eric Sandeen wrote: > > Pedro - so, are you saying that it fails immediately after you run > > find+attr, but it works if you wait for everything to get on-disk? > > I can't be 100% sure of it, but in a few experiences, the more I wait, > the less marked files are selected. I tried to umount and mount again > and it seems to work well. This two reasons makes me think that xfsdump > don't show in the information that is in journal or something like it. > Ah, I tried to run "sync; sync; sync;" after xfsdump but don't work. You mean before xfsdump, right? (not after). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 18 15:22:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 15:22:41 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IMMetG021196 for ; Fri, 18 Oct 2002 15:22:40 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9IMMe53021195 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 15:22:40 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9IMMbtI021181 for ; Fri, 18 Oct 2002 15:22:37 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9ILrxrE018733; Fri, 18 Oct 2002 14:53:59 -0700 Date: Fri, 18 Oct 2002 14:53:59 -0700 Message-Id: <200210182153.g9ILrxrE018733@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 185] New: Mount by LABEL does not work on whole disks. X-Bugzilla-Reason: AssignedTo X-archive-position: 1096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=185 Summary: Mount by LABEL does not work on whole disks. Product: Linux XFS Version: 1.1.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: austin@coremetrics.com If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.19-aa1 Where did the XFS code come from?: Part of the -AA tree. Description of Problem: Mounting whole disks, rather than partitions, does not work by LABEL= How Reproducible: Easily reproduceable. Steps to Reproduce: 1. Using a whole scsi disk, mkfs.xfs on it, 2. Using xfs_admin -L somelabel /dev/sdN (where N is a-z) 3. Add a LABEL=somelabel entry in /etc/fstab 4. mount /somemountpoint This will fail. Actual Results: Mount says the label does not exist. Expected Results: Should be able to mount whole disks by label. Additional Information: cat /proc/partitions sees the whole disks. Disks just don't have any partitions. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 16:29:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 16:29:31 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-25.uc.nombres.ttd.es [213.99.177.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9INTOtG027016 for ; Fri, 18 Oct 2002 16:29:26 -0700 Received: (qmail 9918 invoked by uid 1000); 18 Oct 2002 23:23:32 -0000 From: yoros@wanadoo.es Date: Sat, 19 Oct 2002 01:23:32 +0200 To: linux-xfs Subject: Re: About BUG #180 Message-ID: <20021018232332.GB9860@morpheus.matrix.com> References: <20021018172002.GA7770@morpheus.matrix.com> <1034963715.8442.45.camel@stout.americas.sgi.com> <20021018181252.GA8295@morpheus.matrix.com> <20021019081435.C312126@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20021019081435.C312126@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 19, 2002 at 08:14:35AM +1000, Nathan Scott wrote: > On Fri, Oct 18, 2002 at 08:12:52PM +0200, yoros@wanadoo.es wrote: > > On Fri, Oct 18, 2002 at 12:55:15PM -0500, Eric Sandeen wrote: > > > Pedro - so, are you saying that it fails immediately after you run > > > find+attr, but it works if you wait for everything to get on-disk? > >=20 > > I can't be 100% sure of it, but in a few experiences, the more I wait, > > the less marked files are selected. I tried to umount and mount again > > and it seems to work well. This two reasons makes me think that xfsdump > > don't show in the information that is in journal or something like it. > > Ah, I tried to run "sync; sync; sync;" after xfsdump but don't work. >=20 > You mean before xfsdump, right? (not after). Yes. I was trying to say: "running sync and after that, run xfsdump". Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9sJf0WIvihXTx06wRAg3YAKCN1Z93ZisjFLfIqq6KGhaeSR+UbgCfew9t EZgHHp2vUiWKDKAJ3MU7yc8= =kki5 -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-linux-xfs@oss.sgi.com Fri Oct 18 17:58:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 17:58:16 -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 g9J0wBtG002081 for ; Fri, 18 Oct 2002 17:58:11 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 09D6A2FA71 for ; Fri, 18 Oct 2002 17:58:11 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 136212FA71 for ; Fri, 18 Oct 2002 17:58:10 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id AAEB31967B for ; Fri, 18 Oct 2002 17:57:59 -0700 (PDT) Subject: v1.2 installer crash From: Florin Andrei To: linux-xfs Content-Type: multipart/mixed; boundary="=-6JLP6B02HK6tHPMR+8tQ" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 18 Oct 2002 17:57:59 -0700 Message-Id: <1034989079.23919.1.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1098 X-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 --=-6JLP6B02HK6tHPMR+8tQ Content-Type: text/plain Content-Transfer-Encoding: 7bit The RH8.0 installer (1.2pre) crashed. I didn't do any of the "forbidden" things mentioned in the README (text install, upgrade, use grub) yet it crashed. I attached the crash dump. The system is a SGI1200. I cannot repeat the experiment, because the machine is not available anymore. -- Florin Andrei Writing a book on wireless security is like writing a book on safe skydiving. --=-6JLP6B02HK6tHPMR+8tQ Content-Disposition: attachment; filename=anacdump.zip Content-Type: application/zip; name=anacdump.zip Content-Transfer-Encoding: base64 UEsDBBQAAAAIAIpeUi1qbz7TvU4AALAFAQAMABUAYW5hY2R1bXAudHh0VVQJ AANkWLA9maqwPVV4BAD0AfQBlFtbk9yokn7vX1ExLzMnjmV3ly9jO2IffF+f 8aWP22fGERsbDoSQihYCGVBVl3/9JpAgoNqe2JeuzI8kuSVJJqI/a0JZS+i4 +W1Sxm40o0zaDSVCbAQx9h9Pzzab11ywzS/3FqPvCd7eI5JQJTtyb1j43fn4 y52N4JJtfn/86M6Gy82OyE6wT0x2TL8APU47KNlsDBP9XbpoDS38xWWnDnd1 IfXbP37SGD/cm7UaNDPma9nwxYMnvmH9gya5tPCHHu5KdmNfCE5H1v20qVL9 o/tbrz6rveruuJmJpbu7g7LqA0j8VHGSzjr/8Nxrj/VX1ZPasyvL5v+vxu3F Q68x1vcaNd3814bMszj+1i+S3glNtLAKz/RgfiPw5x8/a2eGGSUDM1k7D+6H nttFy4/SVTRHY9lkfIMz0ZZbrqS526n3zJKXTDDLzG/Q49Ew+/PGUt1soi4u QnuFOt+W2E939wOhlu+JZT+dLye66nwYLHatG+aKcMM2V34wr7RW+s7ml/1A wa4HtukJaO5+OcuKn26q0rOzdwp20GZPNCctzItrhEvJtN9jvSYTe3q2V2LQ apmfbj4oyc7cEjzd/M+vUdevdza/NuTof57JX//3TNOnm+bi7OzsMqzF5o2r 7RaSUTdZG2OJXczTs2fdxCU3VhMPf1ZKgOaLs2eL3SnN5bCBHbq5XFrBzQ5Y V/acGOZ/NfnOBSdyc7XMs9L26eYcQFgNs8uhFzCjXSX2glgiKgj0MzeZGaQ0 87/LbPzvUXMB26qQ+c5o0dzLD1ebDzBrmyum90y7nr4ksurTS7ZnQs2Tc2Dv eKth9pmpC9JsvOREwPR9YPag9OhmJamCwsWWHXjVcau0r/hqItSrfSUHGB1L M3pFObTAe069mLFKVjP0+vNlNoLXYBLVEF6DDysbfvPh4/tXidi8ZGa0at68 knuulXRDcqpC4ZXq7YFotskG7Eth5ozv4itpmbaErxXBJss+vtFk3nFnvm+d sGRBLqAm0IyNeZX/Zq1mhwJZ5OCMv9D89urj48cPnzTb28AnBUgZGFJXGsVb sK5K47/ITGr7+uPlK/z50WS5oh9N1R9uxOIEBZstW37HwGccf6Dm/Ow9+IFs pdHIEDEBOpgkcX72QekDG6rhfezBlti9S626xTkobo+u6qUSldlcwu8yLNVM XIJl2sqwPylY7qqZT4sxFXT173ebl7CdW2LyPQdUW0umIQRq80LJng9L7Xyu hNqTwmocwuq+XKkFzNSZ6p+8Y8rXnE92OpIMvBieSx49sK4W9F567cVnOGEb N6iusO7PC3iAsuZ/RjgG6t79xdpsNkIMY8JZk8Gw0s4Vu+G/UNOkpKv65Ycm 92UTFOGJ46HVx4DSow1e+hx8/1vYFXveLbA98Ui+5QB4cLVw69z5nQ34aUmg KlJN59rOeDgcjWdfOSWa09fggJhHwBexv6TM6YbG8azQqjEiSecbZwu+G56K opHfZmReJmDl72dkXmbH5pLp0N4bWBgeYEdlYm8nmJj3ZIBgreYb+s9/+toV lo0jL7kdnWMX3l1+8ufnnc37Z3+8evnqz0ATJuD4VRNyUOdSce8ZgD1+fPn8 BZKwz5oZ1hfn9OOn59z6Sp7KRuT5bUbmZZPkiWh6BVvc+jPozuby+G+biKyK Z9kNmWbBwlpdHr+8f+fLrl6m36wGcF+5m4KSqyQmfuM3QcZVEmHHJTovPZo/ YceF4j9fgxVtM7L58/V1P/muIkCdSV2THFpXK2yp92TE7mQ82qcDpXzUXL38 I9RAJlPyxVn040deFunm4vy8m90sS2uKgt8f3o7HA+7iYVX3/FaZQs0tItu/ 17L9WyVP/l7Jkx8qec+M9xtv3hXjXOH/FPgXOKBtoeDLvm8LwDnkW2aOYmR4 Sx9Wq0mIooWEq9MslotSZ1r7CFg8GjJEL8we59t6ZA9Twd8QCKlLpKsk+lLD DUTlc0OFixRxSORwvwsyjsqH1pLgiR2Rm2Uf9gj85tICZ1nYXNb62Ydysp1D V0jLIRgJTRLaEE13fB8aIlQgLDLNpLu2fGI3QUTQHZt4VBq5rEkyxXn3DJzl JCNx7DmSV/WAiTGFQ3j4xQSuYJodE3OJeKdkSkwv0vU/gdp5W9d5CR7EzoGe YxfmCadGj/g7H1yGHUo1WoQj8ikyO/ydt/MO+xToZrBj5JmI4o5sKMkKmq7k WMmlKQoAk1VtAIa2AEzO9TrnuM05WWiWKudmW3Jfn3/KAbMPHFqDbcyM6+XJ vN8Wp9OO+bxZqxOR40vHVQ9xVckVEnC6rFTz5eIitAM7kvoQFAsjG9YhQIrG wCQy24v7sbrjwfxszTc3kJivKG5sR05wrBTMxYOSfZhYsMVAH5jpw45qiTAE KYN3KF6mjVbliOTg2nCyt10vlljOGNVHXKrIZHPfDg/nYA3uwidUASKXcOzq LYHNGYMbpuV2Au+1+sUcaOh1sPNWECwFooEdHVAlVasC7skG71x4VF6j2WJj WVq1jD+VygFlZ6KJ29HngT0GSvMOYpfVTeVAPi3L0LRL1x2DusUcW4WLFuim 8EvtkVBcne983q5UrtLz6RiiMcKmVXhNy9iaEuqSgEa6VH51j5R0JNFdR7YH sg96O4a+nEIaHSbOywjSMjEwiWVz/IVpkoqTis0mMwPX3ne6IyqSjMZjJTL5 AKDT3MQGdmO2R4FzFjQTPEvpDkJnvoRNQPkc9hYVkIL3jIW1hJkC+aZrc26g tGJTtJ9Bw++/19A12ZMaU+11oQ0GPdDrUyQfY8KN7XzLF6fgqfx8KIdhBPHp XgAMxOkQNJiozKAPggmEFAMOEeYS2VA6c1yMGdd11soGf041pIvQiYAj04Bt 4FZ2pyLk+8hYMoSNQReMGhyRW4NnNcfrjBJodjO/vgWe5bSdZ7IWrIa0aJGI vJk9lh/1YhpDjKjYXHYFB2MIHkQZOnUPa8FZQJLvwa59EH8znY5LxuGY1S12 rRnHrqG4dl0XTL/rAEYEqOaGYSoPALsmg1yQ9ldTjftS4W6BZWdcGIxp222l 3gqKUn8iZh1i+/iLOUu3i8FWYEJc4ojMCDvck/Ar1IAktR0WMguLRJHpe3fF gDJ9n7XNzQiRIMWRT0QIPK6AxiTdU3nDioJHhmjAdqgEAWOP7qg3Ble7xG8q NOtEjjRz1yNqtovEWAEYGEIK+Tt1c4y+EOnG/R74d6JxBizB2K9bprCrun3u 67r9oEmwAbbtjftGFZQnLhszC3UYE9tEZObGehKOF3bNaJhnJrgcg/2gJV0g 1USdnhGMT2vZzEhYCiYN1RxDA4bry2YeFofppT2uVN5Rz6ebHGacEYbKnsw7 bXdMM1IyzSDVxCLkZjzQeyWWdOSzmylMLbuZ0aw8lSu/meNM9GSKv1lH+9bg jUIPmQ6EDggjk0syiOInwoPiFFz6XQSOVKAT7dOHrMSuJtZDnFRwQ6rlyJS5 eEQb60KOwAl2gwQPtxiOyL2DOwKzQ3Fls9kIgVbK81M9c3I9cGuRz+izkj8+ vn3cfDoBTlUgXtfHy5fixql3V9GSNZMK5tJD3kv5PtEusy4YGN6kcApWKI04 QmusFlM2+KVqDuY7NAfIqz0cyGzdh7jkjshUAzshEYGyWDC004EcQuowYHiX IgukfUgRaYmmvAYWyKSIYvCBK/OflEJphz95+12DvsTV6FoE2ykRhfDYzPym XfqKvVUm25wD3lcMrjdISQi/emyXWQsHTyiIEz8MYTmHnTI2upeSz6c/Q9fM IUdjgjzwHo44iS1z9LaOgNzYkjwOCuDahmPTpWzgNMeDb2WbEM0UIidaPLju 8WFkesJ8eRg1JL1h+w6CdDiFjtoiiQHW4IOrderTZeaQ31MiT1cqZQAJ6Bgk Idhi4hv/fYEWcKGxgV7LHYOOYXgWUDCo4PdSvXVbDeCYE5HPSlyHdcYd5yyo cQ8KWFzRgLhUveZj7HIeUYxgMrkY02Ttenxw+U4mB+NqmUZ/EaAURK7sSUeF Gsdo3x6YWIx7kOeuE2BlGea+LeZKZi6UrfmTpjLDW/lTKX/pvz1FcE6z8cWC LIMuCyiRe2JuKRhS3lfhdtzZSdzWuiTOIpZ8fg0zJp7YiKSLLOT9cQkuX64e zRdYt3ckyWUX4z4JKJr3N9ttnt/3FXcyfQ7L3UEEtxV7W8XtSc0JzhiO33Eg QKfx3sXROxh9ZCam8ZSLTGGvy5xUzMlSwCvhEsw7yMWwg4HOa8/oh+fCrX/b c3YIpGa4X8BnIqH6fqWa4QZceJA/j9jqEyGeC7IGAZPHRmAReJoBkXfA3dZh JO9o5p88mFi2TURZZ1sLYujmqWZ17XYE5wnhYtTvrDKWOLrUmtksMsUIFDEx ER6WGN15KhcLF5bDd5zE3RZPhB1xaTREZGG1du62I3QaLIBjMBPIrFc7dhMO TldF2VkswQSQTkfbmhDvbIcRnqeaAwu5gxtPWuydtXO3Uln/Az8RueCu2h1a rQ4GB747+Ls/hUxyaBBqmi50hU8YKDki08yneHh5qqH9ECOUWJoNHOLgmFg6 8iatHKz6Icwol71CiONRb5CXKJDfcIGXFClP4DPdQWaOiuDYWvB7NijxL6oK puHz/hGKws7ukVzdCpQb0k2I36yHHtct/nYkc0PcUBMCXW46+WAsilYg730O 71t14yKnIxZxqrBtS4P4NZzMFjOCa6o6dnfGgm6Mt0zXeNV13Zu1+Wv3em52 98vniXnUXDx5ch4QxfAXXHL8+n2NBxfgY7xuHMvrxZFAptJhZDCSkeDwA1kI BoBTVAjnM15LjHByke05wjqMeGyDHcNvltyMlAiKVHAuI6y3Di8ZEFdC6bS3 xq7Fmh1r+MVj2TzrNR9JjBYTHN6v1Zh/vlaC+FitAsNztVvB5jkfHlYl7pla CYVXaRW22FosPg4rUXwQVoH+SViJhVdbFeZeZZVQeJdVYfFlVgmnF1cVHN5c lWB8dVWi4Y1UiaVXTT+Amw9HqbSpuh3eN9VYfOFU4vE9U4WGF00liI+XKtA/ SzrF2KlSfIdUgeHNUQnic6ISTA+KIuxeMEwziQYOwXqnpGlGYlkNuUfHOtp/ BJ2jtbeWKPltYVrVuFTELnLVPfGV0f6BWqoQ2GaEv6KjQtGxkoSI2u/Qugb4 ecakIeleGMra8LY00dkx4hA4PyD4Svs48rnTyVCg6W1guqUt8EmBNxCnBd/s qZJvNtexJh6RKTuUsg6ky0FNi3CfnCHHaNIn4xIulGX4mC6mSjxvT4bnhGWT EcwFZ2LMoUsc3ncEsoEdLyAOlcnaHFiodEB2dkCO1o0Yva28c/sQ/c+C2NRv j7fuS1OJLEO7pCAtopN1/4NQQG5f6BIy8zHxGJ4DaeGci50JZ68gc8wsxy48 tEOmx18ejxgf2HpiH26ox3QJAtSC39dH/yIUUUc2zz9+/JwVNS0fJjblyJq0 RwBjaGRnOlFYU0yCEDRxXpFVi47TEpBlErnAGsWM8drYG0+6+UYOE5uxh6mI k9jDlOOqDkwh4a5kUgg6ptDWMRDByIyTEFv5vFOS5iBliL1igj1eq2jxkMha jQ8RRnENXAzwRjF/i4T23Xd0up0dYb8Z1rl3Klh74l0ieKSwWu0J5fRVxnNP KnxJAZSNXVH+YW0QDnS+H31ejkT29ghYintJqRGNQ2n0oTOJaf844/TP+BXO EUIRrKvbh/kuc+y6ZR2Xfd71/GF9TxpB0id5UmTHCGSmodng7tDXu8YCKaou IjZr4kAN12i4RpLZ7DCrdf3R2IA5TkrhR8IRwoUR18llU0iBC8O2rVpiLLN0 35cAOirvyAJLCU2hHa4W6Sizi1cPK5vX3StqNYkH280k9ExDhwSZ8Nc9nPXS gUxPFERM9R1heZ/TWRsi3oOKXQh8Yfne4pvJQObCvI2PqhzJw14LZGZzDlBJ qi7R9qsY5lUL8lUz8SmNo/f04v6TB0lBYEut2XVS4kqNAVt4zZdSFNPJQJ6U ucus85ove9K1PCObroUE92i+iRqchxrMtTDRx2aArMrMZOeCKcv7LY11/UcC vB8/R0RcPEnFdJV0eVoiy4EPLk8vmLLB9fY4MlX99U45cZVE/Mzg6XidH5la FqDslrCEbpFd7zALpBpDwvF9U4GtZpNjt2ioBGvzGuJpjvRpafmOGcFtLrEt m72e2RCLHV2qBOdHZMGU5ZMcMvKkLL+ad4ietUofc3Og7FP6NuToIbUAZNmC EqtZOLosnbPNOK/9nOt+AnBxXjBluSaH3H8gW/bY30cmsiqbpwfnD5I2z1US Zp+65+iqfUC2BVOWZ89rTt7VBMxC8BnbcnTZujubsqlCttLA+z6nq9IYyCC9 nuE5gI8KgYSsmyd1nin1BWj94OchTtXqJZCtqpk2I+sypnO6LN0ryIZNyZUS BxmPyUCXU3jYGwjtyJRUJKCUu5mSwpupOrIAuDjPBLdZwfZEdJv+UwIhI2xO VxUckv1rheD0WyIKBw/s2GXMN7vS4eOn50Q8KyVNRNGkXG4gzM8elAtuMECY vhpIihWmxCubTxXk2PEFD9K5djVoZWOGBRw+SfZM+rQllGF2QbPW3833QBkR sndhFJrgmnGJcB8u9iE1FEcZYuppGy+SoXQKW3kidA0sJ/dfLbHDLm6P+8nR MaJyNOqLT2QndK7w28zhrXbONTSqjwC+rcwAVgGsroKPnVcAbxFX4LpWOqoK wPvYFdALArBs8oB9CKYwdfFyGfJA9401oMwSGv5lzzEHFDjkrzwdm70BmdZb 40BCMiC7mN0h5OLeGlIc/2lr4mN8eTG5Jyk2ts8ldxeZM37kdTzFf1CaRvdM xT3hQtZd2OPrJmBMfOo8jS7PD6Tqvrqn1V/XQC1Ba5jmoPAFCqtkG9ix8YEX 0OsNd2Qy65/UguEIUIZlF8npfmelm/RKOwLrJkuImhoujXtahN83Ysm1Ccn7 wEo8ZaYRgNr6BLilKWlMJWZukZoNLsUc/8OqDBwmbcN9wmQb/NeLaXU0E0b+ 8JteuU//R9yT9raRK/l5/Ssafh9kA2lZku9gMoCvxEZsx2s5mcwGgdCX5I6k 7k4fluRg/vvWxaOl9lj73sNbA4lYxSKbR7FIFovFUjikKoVeYO6wroTsshBs WTAl3tR7Zq7noBuMYhs0aRNPKoABre0gIA/pmJJAdbaMhEISDGVlnqA2NKct GEHZUIWqvIhUIgov3ddTWMMwguEFTKJPEfC+WZEICyvAzkihDDciyjQ0QHhs MFbUBNQzsJgTILYZ7OiwvbkHVCbWPBy0K8AIY0yYRLNSB2xCs9tH6DGTpv6h jN6TsWDUsV9CFvto7RuJRV8iVniWfjhRGgBg14FYuHLQVlojZhKqfEv1WywK nhYSETbwa1gHw+YKUPIUu9PuYVIDWLNURyWpQaYeS1j4tZoCdv7eEw+eNIs4 Rww87vZ2NRYBq8MQ9UNtxRDQ1VFA7a6WRlpfVahC3e226Lo9DU5TpVHQ0FIu hOt1dQpLSWVAOktYxum1J+KUdlTCrleMUQ3chLPswFSMrq2Fs0QCoyZ2eKkW iNFWB4LoHO97dfhAQMseCVegpb3EsxFWl2ViS5B59oABaIDaMg0UU1/Cifod pSZUS4o3ya1g7WNFET/po1pLn57pBRiFzBjMRJmZBYFwTRbEVrQAdgEC0XVj wMaHYzlE0pMoBtwTvrHnPni5jnVP++fufaSUxhoLLfjFzHKEO/twZfI6uzu5 tSARwe7/TGLfSkH3ifr968hbGOz56blLN5hNekTdjWz4ygYG79XZBiNgPeue 0Ulwx0LdeIkYZzAK28PtL6ZaljI6hkVZ6V7enJytIPuXJ12DxI+6N3QLu4ZU 5xAW7PZj1CRYZCgnY4i4v7M+c/lwc+3e4Xm1lQMhH7yRMkcm5FWCfmZMytuP 7y0A5pbz275B3KEWUQOYP3RpcB4VgRKXVsyfXma10v3dTc9Q9D/cXPfFoogQ D7DDvY+88GNkdSA5Q/hoDvsZiYZwl/G9LKo17lwdSxLm873VsV+h4ufQOXZr IO4CpvRQ2VVp7Ic8fYrqqOWmRNzDLLYS4v5yNnPr40C2lFGSpCvIOmVRxaEW SnQ/s0u/buiPXD6e7BiENT0plDVtE8oICIC0RQ0CegJBQNnpCKFZLCOUhnKv AgGzaEaIFykIxGhmE0oYzQ3xOgDnr0FbZGgkyFx7qs6IDYlCmeVk45G1WEFz JbXozXi3hiHrxk6Wip0vesPQVU6LcijnMBhG/1yyvjSgS3eVlEQxaKsZDfKH bhaD0xOchUsb6EwfWzijA7Cw1pxmYZV5jjq5AWHI7Y24PH5K5zJ88jTgdhRA bw8QkMOQrPACOWTLipGoQWChHxeBBLUZZbZ8yzcrSk/O3DPL+ierauvV7Gmq ft1RJYN4NhEzLgrZ1HPp08UnmIZBmjPVgu7tqJ5faMuebKEN/Dhosxkjaops a+auz9kWIpV9rsDAUPHYJpCVNlHMh0cHFn/+tHepQPCTefFnqeYgwrnatwaE 77hjrdivpQqFURGPEuGAn/aK+mfZE6Keoe9ZCTRCNSxCltb3Z6nNzDlok1Ze UnoSTMU4L/fCJx7iuReHZreRe3kmeDkpzkOlAsptE+o8VPfxc5DxEzXUFWBV TqH2eH7Ea0yiTuGgVdQ8CmEj7dqWIYKSayn6LnEdbYpYQxuTxjp+HC381Msb o/AcsPTysiEOr0hWaq9cjyIdQQNeDCSaYkTBUcdm2rXQahSeZgjzNMbwcGyI FZODOjqne8qwtEwb26GIYDsb4+U30431+PwJtgFNBaW7WkFz86JOuCnNfGi8 nkjMJB2lxRIC1VD1JpgUvs050yipaolAmEZevWvybOpag1ywxSyGJXVTK9dj rP1LLV5L4xVsLUUMDVDbPuM5hrLYzYG+UMFEW+V3CVQiNn+UU9l8KnHQk3SB TKCqFCPOHKb4LEvl07I0w9r7VTwJNWSNVIAskQpgj21sKTM6UKlHw9acq8sk sgvM6/u3vFiI+lrf/Fu6+MegEtT1W4AETbXEQAhmTNVgwk86aC+a8pk3mZhQ PeqR59HCm/osECnkWndXBWHuxjCimEltCw+kHF6WjRK5S1rDWM1KeKX9UKSy yyq82VCZ7bEdG8cHeDtwHEVqgVvIbhF1s5rVFOAGrG/RsGlagxL9GGwVoCFi T+WgdPcU0idMuHao1f3RYtni0QvTWR2RRcGQtYUA5EZlX8i2Cn7tFhmPldkn BI2GWG6hdyVkp5ikgRLyxSRPdMDNKunlItHmvgilvECEX7s5YJsOQg932Ikg oqDIeHFaZBN1BF38rOJQh3KQIqbRSy/XAb1y4TvKErAb2Bx7FGWVKKuuogrl m2rLwfICZ9gl0BIfFnIsK6BiMckelYOCYjE1N3eLRTEGkSm1WBR0WKQAkDqp eBsBSBe+VKbapRdnUWzskFgB2eWAPbhVY5RicAK/ahsPwbkEsgHej8yU7AeE vthcBiI1ymii/HRxsPYZ6/C01KoRCrnecGpBis8FeoplZcywuQzIMBoQ2nnN lVkeAHrTggdyhtlLpTzGgC1U2N9PlwPWBANgHMJUKl4hylhaRRp0LBMOovQe qJxm5rStTOUiG/GSuZdAFxf1V0B2CFGczeJcgFIu4Jdl7fqsAuUISoHPj4Oz 22XMwx8KY0w0SmEl+KUyEVBNfbdA30xcvCrxcr5VUOFlDMHF816YGoDXzhZg DVaNUkelVaKu0FRZT6/5JGyNkyqfWT1dFb7pPQD0dSWcMabqtFsB+jCjwoMn tRTADFwzgqpKmvUpnmovQBi2RCaCUfLoJYGIbkTgEdhURMNTPI8jV3uGetIW z08yXT7hYa+wM4YtXpOzc7NufyqGaq37JO0Cv1ZjznYD0WhQpAFxmVEskdTS TdWva1AQtI8UBWOdKgL3egnaQDzx1DSLfG8SP0tzzkYy0mePsTA5zMhiGjBT 2quZtY8gEBdzhV3rmcTUC1MvyNTLpAZTY1Q+m8ooFGvPLofMVWANaeYzGDms Nwh1n2pWudwLGH4K1Rww3+0dsskBhcwBP4Nz4Z+5Nyv5DGNudifzIMzxkpkA j54Kyfw1D7KqKJWebB5GE9ngcdBqPqtN5jVfDgJp3cJ8CHIaZzGBRMDMh4UW 2nPb58R81eUEyM6olArQwW4g4SJM2CoViTAk7h0RrK84AFSiGYOphMT2AwP2 9xAsxnR5C2PTQg/yubJMxoAbyL2aAnWu8TCWibMWB30akidw0aJR5A/7/glh xubuyRxXePwRWuvpy4Zz62qCIJJUylXkPNPMkZ1nnhwXzm0ZD/CCvM0B2SKz +H6R6Y3wIkOxwEF9TPgc+TJlKIH5TEfqlrLjWe0nnie1S3bPshjd2Ng4Fz/v Ue5Ay5YoydgFEN4pSUZoeODjlL4xjWBTAMU5A16dXiHpZHJDuFcSOg7aXAMH sKvMt85vPvni5QwdyYq85g6hWdo1aicdOr+h2/xlMv1Rxyudzvzo4Cjo7O79 /jt8bpKmGa7Q+VCAfKA7jnLxv2Yh6uT/TCmgtemU7TH0AOKZe2ealDt8lAI4 3NPdkW8qxi8KGigQI28ZnJNG79vB942iRKO4vYMNfHLg7UpxX+2BLJvpVHf1 qr2WFBLHc5CvwFHfcjJ139l12ZN8OIDFQoqX4NB/fzKCPRcT7Lmj1CsHwzQN a/h9N0kHaLhf0PlXMhr8SKMaBTBiVHqPg+EkzmoRyv2HDzNO4jVGqVV8c2QV BPDdxrgF9MjACwfoYQYJvlO1ualPJqjaWpCTHnmfAdoDOihBP2IdflUB5jw8 4cKHAxQOGYjl02+w2Gg/QP9/AdBJfbS9cLY+lGOF2xbmCQ87nW7wu/qGWLfj GclrY9OhP1JpReEJzh7Ahcd73f3ObntvX6LLtCRhp4tXlOQxn8p3HRdlH2G7 gBqpShiE3QNfSkjZDWJaPP0mtbkCiEmPO97h/kGHSQNpm/BF8qPD3WDYPWJy LyRneFSuiycYB6fp3C6WwplS7e95UiroGPHc/db51cKOaaka4q2hWu0Qodve O+5C279xWkU1nXr5Yr1kgX/oH+9hMlHqrZ3sYLj3+19UZGCkZebJYbamLv6b 9j2Ohh1pX3KfL6P7jL239XG5sBbX4Osjp1VZpsk136sSgYl/6AaV4y4SvBAd qgLiSyLo35XF17f2zhuHnsRAvUBkHsV447R3vkuCLI+eXvoOOrq65QWTYta4 ROEtlcJiK4fsK8W+ojWNlRt+aaW8rOOy6qUpdq0cG5PxPBLroqxU6C25MEBY ooLZcn+sLWzxD99emXiLS14WaDSM12DMX4T+3tpq4VdHKWmj8DUPU6A+UiJq cMpxjbNdrWhtTC2v0CxPd811EF7e84+7+zDlbb9xdIlAsM5gcYslMP1kCoVd vV6hrKdx/rVCJdEMPy2aYi4QleWeMcA/MCOsVyjJ5N9SLuRELAdeS7rUow0x fcA4g0uOX6NUmNO/tUiPcRjVi3QJmP+XIkXzKIDFMpaBjCit/jtHeL3iUNJ/ qTzbeizyW1SwJNs9OjZIGrC/ofkDzuun7D+jNuVLlJoI9rvhvpq68M+nip3q 6e/yVCHsXAxW5bO3H/kHVj71vpPMGLAzYozOZAi1tDJZGrrr5uLvDe0qYaMM CrUO6pPOOwrVutrkUo9RuR14xz7MlJZozG2RqF6palyn8UyKG9D74L+rqLLl Okya8YuJak+JvUglE8J7enSJa0dhu1KEUHXZ7UB1rJaxWHnNtt3t+NGu1Rrk pUStMDFc4zVEqJS9w+Fh10pZE4Rrfv0Ain9k5fHoW3y6zKEWb/p7nQMrmUn1 ZSnVFysVdPyxv1dno/Wb+sDb73as1DPqyms6zf72fQktOa6y5DIrHu0Pre7D w4u+vQqKksHnPnrGfOOcmW/UJfv6Q9E/WhpEfbmmsdyHNHOdVsMhrRSJFWjg ImJZ9jDWZie7Q/04Wa91jzs9u3WXFh7rs9N+YNWRtem42Don70K/Wg+4CDz1 clhUyx5ULy0H7IOOt3NMCFT9D1fO1/d9nD1hAVU8smbGSk6+MyXRH9EENiZR f5mmoKRI9Jcll9HU3FpjGtnIi79EvbCnFAfSCGqzDbWwW8JCmz3B/p5iLy/M YjVI6HkYOy0hzN5nt7O3Z+3I7v7Z74eHh9GufB/2TbAwNVtY5Lk4aBKFeZXQ PfyjTmd+0EHp+qJIHk7I9/N7/Hl1ISzEv1r4zESLlFUtOr20ngNskS6rxQdx QoMX0HOVAP3io+YEwb82XiwYlqVJD0PM0ifNS2cDTwplrYDs+WoFKFPdFyvt Rg64s/FIM1Xos5tyAeHbER9tv5fQGnsHPrSiIF8Tlr1+mpcTEn0ERvU9jjqS 68j+GXYZUyVlyORbZQILp4WKEJ/PTDQ1nypzSB9G6FxbxCx+XEFVBhu9MOrP vKy2abM82mI2jyELaonlp1DwjUF8BC/g969ebwx2qXb9WEi1qyL6SHbcXNIk LgADSzQvDFj1rqj6dPKtmwANAtQbXIRBa/D7yEN3nSqn83RKrgFMCnyrSx5h 5JckQy97uO6bstyc79vfZBOFjqbFZxPDxPriCXvVsXrwzAsetcYA8riGZNxW HasB7nUDYLa1ikCaS3FB19Hf+RgGJvqabE51gy2nvr3qc6x07D11oXQbcbhh 7yjDR1STgF5OJG7wggCvXxmaYUEmzjjC+cWyflSu0dH/Ye0yrBq8uFzza4b0 n/sUXVAL+JZaR/q+5Ncnvw0LDC8c19W65iL0dlWqjB8G29FzGAoI5X96PizQ ofKUTpo2Nt44zZl1lzPDQdqYIUx/vVdzTKCfl3OEuJ2sLBozhTiI0tl2/g/Z okFcY54Y8WqOUPXeUo4FCK3GDDHCrvn32jLgP3bcAKWNYRCWUUjX2wBjDCA/ SmiNwcQHhL9aHy/+PP10cn/+8OfdBa6NAphOAfdwcnqNcFX8JfwZRpNzso/5 1RrhQu1bi/zF4d48mpBWKuh2ehhofcfJGh3IVxkR9iUM6KpQpPuaNK/cIOv2 9rtErN6S3GLcNmlzqhc/4E5K+xvOFrtv2n7pY8GQyOWZVPUILUYH3kCd8Dd8 LULrkjjhMorPNtLnRKvEw3xwdlmnj4vCkW9ucQSVkCibMnCzwC7nVhYI/Sox NB8tkaymu4lhj12kw/Ll1hu7P2ewgFpw+ciHnbRDMR5IVMOnevUPAeLFT0Tc McpRITFKQ2PlVXc5z5c7PSqks8mRXosxK1Rx6cb+lCjVk69bV6c3lGtcNhXB LsFL34ZOsbq0sTNXEyUpUWt/hS3GrdCFir9cdDflhTCmuaryvK58x5ntgBR0 FMU2K8pq2VnpuW4D2PzWWxgQSy1sxkflEa32Ndhi3EqBs9JuDeNckSgb2jgu 7f54qSfC2jCr172pstIxVo+81BHZRAo6EcbJGoRW8IyfZx4n15xpYY+M4Lmh xGO7xOdRMvXycb3I49VU/ojIT6sJu9JsMa4hdzvbF3OrtdppNKFngLc0morh N7RcMVqVUo2N/pKUIqLO6oDovDggwsjq2pd69JEHpPY02mLcCt2PrNs5IFLl UbRF2JaO02xduB7egUt5VH1u99vyfq/HxiE8XwzQh/DqoGAxvSzJ/06Ax9wm 7I61xZjVtnhKc096mIMGuVKGWPhSSzRAvCjRhnFNVskz4TVh1VCePDWyQryi kphokFePVbfTrXeSswUoXIxsv9RdBblFjfSUE6kvFA2F8XPX8xOptHlUfuvk 9PaBK+4TezGR6WfTvxfJSA32ppVAktptZJ7PtlupSVTHhZ1O3N5SRzRMRSBR gPVoPn1uEivOFsdtvyRfKuaPz0mMj1V/hHVcmE4xduQr4q4mLvOfRC3uY1uE ahr2K+P9pWHOqz9+cuXujAAfbaAi2Uij7cIzeQB9kNAaa8+KfKeq4KfhsDB6 CS/XceXzW+eEnOR7O9dpMThJRmgyyHqJQlLgRgU1/7hdhXXyqQZR8bBGWawr QvzVMP3Mm9xPyWRh77rjJPL0mUQYDb1qUp7LPmLq54ruQ175X4z9hZejeosf hT/JRxW+2f26Vsyk5EJS8us0EB+OtD3jDZ96rhQrTgrD9TKX8vNOUnAqq18t RAKLbLXISBY54R6Y7xL2ItcKARvL1jZzB+tz+Rr+TlQGO+jqqI1YbgEfRjow 1J7WtJAe71OGdSksZWtW5ZEFMplqYY22tm4M49NwrPX6Brg3EOHjfwH+F363 stIaLn1RSmcK27oguj492e0xkdwAe//5+vr25Obi3eYHkFvAiI7r7Dqi775B Gmfrrr/T297cuPn0uX+Bm6h3m1mx09vc+Hpx83n33WaSQtCKRPLNDfgEPSFx k4bVRCtK9P2yWw6s0ZMhKaSMFi4uzqg3oCm1tgeaP8/jMDq/PLtDD60JHa6I sicquUGp32HTilLt/OLL1dnFO4Q20FXt3f2nh0/v+ILixun9p5Pzs5P+w7vu ca/dPThqd9q9/f2Nq7uT8/P7GnJv4/bi4eak//EdELTVvw5i//h0/9Gi7Wx8 usUvvVvA+IatOpakUytJ529LsttpH/Tae7WCKNxe77ViKMp6Kf6S/X2MVkJ4 yb57fNTuHbcP99vdLnOyaU3sp/IZmD7P2sUohsBUOI9OMUwG3b3jdq/TaUsO I9jIz9Angi5EV5S1sDLhVMKkyAtnE/LDoY6yEXqVR0RlRxICH8Bcg6me1FjR 77FA4JbqSYUB6Or8rfM5yfLUB8Fww2QbQx9i+uRxCGku0zwGEb7bbe+7e0ft fcR9oWdx9zvuYWcje1wUINsnf8QhKzMV4jKKR4+stXGcubp88fX90QEz9zoa cr5Ct/EP5+ExciYiOVHfUgJ8/+HUwZct8OJ+2yGTkDcQEUNrFkSQ0KkYEUMW mBn6u6o4EkYuzICY3dYkHkfOZrucl5tOmkMo9De3IccHtDDEzBLUF00mC8gF 9m1JBK1Vpg5bVVJmIojbG1Ts+5GPBxT/tUlGVl+73fsDkKY+hnbykQ+C4x/O Dbr0zqBE76HuSK1UhTBjRA6+mziDr2xB5gvCQBPhZasEVUbw8RE9sLcNGZ0u 1NffOEq+H7Q7DixnHLxKk0ORZzilOR491+bwlQV6roOVvCW0EWSE9fiqYqF6 OUbm/MSbVEyX1XE28SbIztvDbqezyZH/y97T9TZyJPe+v6KBu2Alh5ydGQ5n hsxKMEVSWlqixJDS2l7DIIbkUBqL5NAzQ33YMRAjD3nJPSW5vByC3EMQ4JIL ECAB7gLkyXfv9n84+JIg+Q+pqu6e6aEoLXn2rtfB6YGa6amq/qjq6urq7uox FBr3NoE25HrI4Ea9WGuSVkgqjSvW6UmBjxqdlqLUl9arVEfZCgpXoCFDftB1 pI45UKRhxKqsHkQRCMBReB4M/+SgwcqWqz+ShzjE5eyPEL/tzeQSItDsYrAZ U7dc+jYSC571Z60OjAhQy8f1o+JBA4nhqHp8Uj86qR+CmttD79tjTGt0W8+b XXwbUhEIDgYlQlYKxTIyvWZXoPSeH9QefwaVuMIeuwKcOi01O5V4PBhg5AJ6 5o1OASgkZzgj4stgfpOuCl0G6dLBaHmwRpaNMkQxrK5ofQDkY/inmb/xXlHg ccilZTAekaoih2uMcczwkMW0+uTJxcjL78NWWCzUOhYcUusenRv54Ckex9VS MO05PtVVh6pctjeHw/Jw98NHHU6HESQjUFrxevR7GZIylMYZaPCHDZzTjWbv 8PSkA4U4OD5pN7loRIuZOMdeFsPiUXqUX4yMOBeRiWtkJ7YBVRlt7BBiP8cC SEdvFXR5aJSxJbnnMUtI7z1R0sSFL1u99GDK9mPeINjuqS8wQxCTMErQK5gN 3viiAGTTZQ5jQlrq80hJC7+EUhCcbSooip8uA8p8fVV2GQZucYEZzpcrKqfT nBouyEuHqUCLIInf4ZKVSLbEaXYMR2kK6Q0UmYjJpj+dN+T0hBupMHhfEUOP +Z0aKmN60C7xpaeyBh7iyyXWfPGjeCIBV7PnN7/4+dc//vOt3/7zn/7mP/5y e4lRx3jJjMqohr9I4uFFrl3E0xK7uNfj1z/91Y+CmZdn29d/8/df/+Sf/vNn f6vybj/yZl/8gxfECv9+9Rf+r3+acPwcD8XLFz+LlxiZPud42Yzn3hf/Ek4U CTv2YazGZopzHP3y7776s68+/+rzL//9y198+UuVs//71z/573/7+f/8+F/v Z+9vf/n5f/3jX/EGzbFZPIWc07ixSmzVWsGSAltFHVKxTQqMcxv+Yz0KWdvz diwIv0aBpUJQkLkXmGRBgfFaFVjK6wLL2hfMIt4eBZYyFB7nImchg4WsrT9M q3WMboW8oMZX/V5TFdOR128c3tEg/VbvXhGlE73awZ7h6iV9SUJnYf/4RJXQ kd9vNBVGzyb946M7stnvtfIy+ZHXf6ej+YvhOx1VKsdRf7+rSOQw7tdfLEvj POl3Tt/2F1G4JI2Ly/5ZLSeJftxv9nK9R+yqU2QwWvS7ZxrqlpxquQz7h10s 4WH3fhGko84a3riV1zNJv3X6mTAZZ0meQ2D06sV4MTNslU25VJVXuQ9rq/wc VsosSuX5Cnbl4FSe4QpF+kFh3GE4UxmWL53gWg43x7ocuMq64W2UFWO+slEy Hor5hHtD6RknVSK/6xCRZcn5RxfD5TqYXO9QubeI7/SwDGo10wgl37UyFKV7 3V2xy/W2lcOAv9TZcJEi382U0smuxlel7na2DDTX17yljpbj0CKv5qOFyhH6 eA8/eEMqHemz1EmrMqEJnX/uP6H9oRfhZKryQnyrUxhVMM1mS6ypJfCYBMMn Xf/28iPvKri8l0c1KP+THk6jL7xgiV0imxNocZVhInkPRrtgpnBKpNemeK/U yJsu8U18PvpoMZh85C2P4FSO0/DyNlS5KHA6XpQbxWVy5AEPl9kp8wniAXVk laXi22HgX+WHc57e9kZRMMqxWfrNj/3r/vthdJljukQL42F4rfKft6ofLib3 ywGvMUUUyQmEINoNpz5KRgJG3Bu0uxejvtEqQwMe1ttuRijcGz4Cuk87/giR 5e5asTFnOBjbLh0nHHn3QjmGOxrpHGpwP5Q1sAYCavgAlGEZOh0p5OeKl5zZ /MBKw5+L3UG0e30x5xFiNpgUyTnYUe34QI7O2tnpftFFvrzf2z85PuVa2YtA vV/4g2yYOOt0TrqnzUYer0rP8JtZfzhX3rvlrsVPpfiyrVZESgHFbesxYLWa nAIt5SVj+n8n48fbWQ8AEqBTvIzA8QaovXCRXDC8HnSYUXhR27gInYtgEswx bmackuk825hMD1jjzfFwriTSO9iYyF6YxNfQ61Iae+9uTEPsQkhJNA43JlFb YAilicKZ2tnGRJ6FIKtg7ZynRJ5tXpIXwXTgDa6zRn2xeYPQ7rGsKvXNReSs V0vRZTfZAB20O3vhe7m+cvxiYzIHoP4ThpfcergzSBA62FuL0PJUTlmoE3P4 XG2XZ0jZch/XUbhs9UEOg0+qvMmkJyFQi2WoGHI7EGuJnfR5nWXo2N8Xd1bI 99oiCVN6FHhYrOJCen3iexFmcEqr4YZYP7tJzmbBxwsffWOGIxzPGCYloBA5 DT6KrCDTwIVLtQU+8aOwPYgkcBAfLq9NRz5kFNM2+w4MdzfQ4FDItNK9uT9c a/VXhp3AEuROuwy80QDD6sS51GzTK38XG1CzQ3ZhFJyPY75LADcIZzu71zwI zcOmpxXZ54dClANcPMTsSD0VxRfeMLs0SRQsoftGPoBPpYwCd8imS/Aw3tA2 dK1bazWkK/npYpbbvpt90zAfQI53s7NCisQWjaWqZC3ApQXH8nxaflQvmQO9 rKtHBqnzpIvk4j3bPj31bnogXu099AxXHKOctQKtLO8Tz2rRUjtyVorjhFmh aZ2fu9kokqmaDZ3ir1/QdY2GLb6k/nNVTIQErDxGORfymhEfxxMeH0DdbL5I +5I8bavuUpfyd89OddE9sF2qrGxpruNWdNuUcTGUJlNKHd8Dze+2MEyrbMmS 8O4iNx5Q0RSVwwVl3ZP/d2uFPb7HIzhmh1fHcShF4NNM8kahCK2gcHBFrAUK TiSryfWIXUr5ESYgfupR2eB8BlYGbiSpQ4Z0CWYSZ58TofYK7LvQPUpSqn6U NFUD3Yzj16iAILfV+kcp3Srts1KPfFM1YupOaeS++WrETKXwG6sR6oQKeqZB UmWVdbaRzFhVIQpyToO4pulqtl6ulB1ddpuHdMgqeK5FnAroEeeOHhmlNV6z 9xq6rZsVPW2L/7dd+B7ev0phse4Iy/CNEpbh74XlzREW846wDFYZJ/cKi2PZ mlmxKqbhuusIywr4B4VlsKmwfG/tgrXmJK9KQlY1ryIlxh0pSffarjq5mRMR wzYdW3MqllUq2WuIyCp4EpFSuVw2XOsVG7GlNPE1GLGmadgV5/uq2daSWDxs +gqN2Iw3Yvuqeuj1O7diS6Zv298DK/ZVTIZXaxLJL/Xc8gbjjaGbjgamhmlY rlQEDyqTFfCkTKjn2enU/NXokox5r0GX0Ay/nPLl+6VK3mwjqXxHaEebGEll w9Fs163YVjZ6PejCWQHPjSQ0hN07Qrvx7Ot7ayNtICboM3293tvMcvjG4863 4IWFoeWVDTzFj97IoeeBHlzKQOSc+E3qwRtPib+FHixWoxZJmMp7N1uVwQU5 TGciDWON5Ex9pXVFYVOfpWIhrurQ6oZy2QT0fEcGxBhu6LpsBoPanadLIN4i nAI1Mn/MKYi8biDMAntpHdEj/xrrmVVTf53VJMR7akmhYr7dajq2u4qbRplm e79rNbk0j3yMSb0UvIvvIHn0pobru+l7XL31xeFhETAUj6NgKDfauTMOZiN5 Cd9jHkRO1G6KB1ZnI5FIVYym4ptIzE4We6MrHhZGfPDxNpRz8aYGvBJJePGP vGoyyzajt1QUFCqR5KnrzyINihlcZVHHFUwck2HAkKneaISCJ96wevxawCiJ lTQRzfROc6CcjJdaCcnFeKtrrJRnPPJibAqTl1cJ1raqEjKiL3z67NGjR0+S 6RwD703C8+qjp9YunSdmeO05nqej849u0bBAYPogMH1DMz0Dj2SyLazL23M/ mgaJ5vHdbbE8arnNts6Hw5RMSTNhONZhRNZLbCt3dJm5mo7fi872NvuBwd6F jycw/ptMN6uGUS1VWL1xStiPntq7e62THt65iEeCRkyeT2TdWptOiGANGMH4 romXwiz9saKaVBlbkLS1iCle6wO4HDCH6xG5rcin00Kjh7B9dzlnQ18b21gu tzkejzn2S8qdAuZxx0PErdU7LTpx+SA6wWboJdmKHP34ee9e7LE/XC44JBlr Vnvs+3exfWqLdbDHYzePbchPOezyrmM77T12dPJuu9lm3pUXTLBFNSQ8pm0H vXaHtTtFMgvJJAXqtjfUEeJiijfDn/s8EYlL2iy5xh0Kd4CcNYAq4zWAuPCt ADqZMdz8DAMvhSSdi8tOK3a5YuJ3jAexpW9XmaVXbCIXa2m6sY2gpnX3i7mN Y3mWiIFaJvzcaycK8XaPMGI4aQrGMkzklaFZxCD4ex5EyQJ66bsBnX7FG6yD QTAJkls6VshLDhzAYbt1fNo8QiQgPFqAIsDEI9T212E4wg+1TqvOKIbczX6z SWxFAllBQIt0UAcuplsJaCL4wHGkNjKcJXh9HfjWkxOe/AOTPU+/8HnKfrNO 5dByhKHlodFLu+ytt95inTCOg8GETviCoQvmBYkuvHK7l20F0ceJ6NACp+3N bgnKj0G7JXiD0jk/FY0XF3vJAprzwrtCj84whIkotlb3j+mOUoJEasgwQa41 ZrfhgsW+T2B4VnziT+MCoPM9W8PFxAM+1nstkq0kppPHuKc7xnrSxg5JjKaf kCHe4AIg0egajzZfwcgLLYpoXnyJkSYWYHnO8QI5LIjNcffwglQsoTejHsaj aUAVb5l/BaMcnV8eLM5ZHKanvimwCbUvD92BcjSlg9F0nxldgzXa4f+0YHpO W9p20KobxzuzkMZ0FnlTNAH6aKrtVEzDZjiU9Vvt2kFz5wpvd1x8wrCYLbld DEtZ75z9gESsIXnlVMqaW3FY+9knFNaQ2E2Fk1HvroqGBl20/rxXZacLn72z AGkxmGFVTbNaLrGmGNMYLzrfmjZCCjjZCXESOgwn2LbPD2p/yFz9xizTVwAc RB7xF6xEaDG8c0nTNDA83YpmWmwvPA/brU4Pq9EGWwYNV8eu6LZ1+cRx7ZLt Xmaqjm0Zhu1cSg7gfdEFKKRj6Zepeimwkg2vOFjAN8e+pBIXGKRdBOcXU3+6 jXk1eCzHIcZGBYGIL7j8ZWEzjZKhOybbCiOKDeMCMd1yy47NBrcgHtu83VF7 3U/DLoN5nZJwCqxsWqbrKhTaxOgHSmGXXCulUC7IYkkKzi4ICU71SWKA19dB csFSF+dT6XHYVUG9mz4pxx2YKetlescQBSJRp4QAqyZfRqI8HIEMGx41fN2q 2wVm2qZhWWnBQfFAbsX7CQj4B9rf2QVRr7I9fxxmfZkze0jXUOkl1xkPxuN0 qE0fChJ8Byx/qA4ROjJYi9cI2/2wgAkNJSEDNGWqWcZkUZDaGGMebFSO9AGH dyAiIs3gVT8DoAW9n0Iwa1zYEtI6dDMdd4lhtKOLAHs56tbUk3UvOL/oFTuj iO3MYFQgfaGltaAxi2pyzmPWKLUovbQWChH5V6dr/DYhYnEivAZirGOtVott 1cM5mfAzf5thwO451kUvYX3pRh58HXsw2d7HtsSxBnUuqAa8nArVzgjsAy0H vpjhNdvQFL1Wu0F4/s3Qpw4kWzSHWMeWRMTHF5PkMXk4Ixj4ARzBTg7zQCCa bA6zmREOECkACP9Jr/UeTY1xko+BATB+OWIMbtnZcWu/9R6CSTY1bxKwNFJu 4admr4uBVkBZD3gH8GWNrkAeMMyF2qAZtEe8fRj4uLZ31Do+YK2TItkQMP7G NFz4CZXRxDEYRzmc0fQDvN7Nx+C4fZjUYPWhohSiBGEljXTywyk2MNCHybBJ wkuSPuwxAN1XcnR2U/Qtbx4Mg1EROL7NzCL0YLNYxp8K/hj0bhj0a9Ovg78m pZsm/ZbA2EywzWc0LGq8pKetdrNbFe2wo9+UDAZ5GDsm/jN3SKZFd4ShHYZ/ NEZ4SAjUz46WB5DlBbMr8s8DPBOGysyi3CSPsela3D7TVv9hayPhVmrFyXQH W1dLiYM5iHMJM+uAggJ2vepSq2NsepyY3qWBl47qBt4rZyzRYDRg4EX2AZps 2C1SHY0od8E70EB42M5HZzt3kd6BkfUSRiuRMlYVzKzmtEueihcNwIASQc0y AG5WKgXmfnKSp+Muhp5gnYtbsFfB5juNApDRbhcs3gnDmzMwzAT+TAKwmzEU EWOEyDUU/kMHGkNnIf/R1Rfxo3MUA6uF/5YAUhQj/SlVOIq5AYrBUUrro1gC xdoARRSsvHn17fVzKYuCORugiIK566PYIpfK5nXxNkcZbI4y3KAuovqj9VEc UX1/AxSRy3h9FJfnYmzeXwxjc5Ssv2Ql0MXDcsF4XYzS+igVURdr84KVN8hF FMzePBdnUxRUjTDywtiGHki0n+KqSNdZEThdNcWrwV8N8VriryXxavFXS7za /NUWrw5/dcSry19dSdkUpNOsBHFDUjcEeUPSh+bkCWWZIGgaKdGKSKiIBFNU wDSESfLSP2nkWbtneOcshX0TI2ciLleFQSlazBPuVxoqs1sFSgzfnCQa9XTT OIvnGL0tiGk6XjFLJs7HFUgMBghWYrwMXqloVgU0toQezhd0a81QLAhVKvi5 wOIJLQhZFccqm8KI1p+e6lUAcCt24dSo4jdLLzSqVqFX5YCFepUT2EWUaRKB LYjOMJ1tmeiJLJnONusGQ/SZsIMwxBDN0Tn+f9tLZmNtGAdRqHmL7Qw99RHh q1jRIlse+dCptzASbIu7kyL/KhCee9AXfEpOLqrxyBtAHSceb5MdM8XlrBmK KJXce4d5MCMjH4UDugkUspG+HvQEnc0uZ+H1jA2iYHTu47SAzDiQEebF8WJK phne4T73cJvEQyjG5ijm5ijfccFEc+Lt0hgDFFcwRLgykM2IZBVmch9AX/tw iT3SrwdQnRZMdD5wddd+4hiG/iH3S0Pf13SBVNyVJj/PHqdEVba1pxdaYNF3 9G3sx9jPXwptptCVbx3aktCmsQa0W+iUUmhrV1w2UWWq+yxdw6W7TeLbWXJR 4P7wrXbtnZMuw1lNu3UMT2aZvEV8Ceq4eWppOk0teYKJvmt7l64CYos5dIje NZTH99jZLCALO7nFaficGNILh4EPCUCmpOlod1p5B2L3FMO6wuwQlBCoGD+h qR+uEOPXS1zUI9ffPLklDwjmclNxGbzHacdE76ANE0ZyZ9D6dJR6qMuaXh5y /VLUnaLubnO3Vbt2/H4fT/73WO9ZrdvsY9P2mt1W7aiPfVnMhmkmldz2dK4q 9NLYJXc022HWNmpMD4bSclmvSUBDAJoZYGkJ0Nql9XXaumhhrJUkBiGP2Md4 HWSBDdCdvQN1RZJQXWQ1X1AodiZeQq/NYqvRlFXtCsVWZbZWIhEIMIZqTfaz UgmdsfxqGOpIXN0jTzswN6JweH+URt7lzRPgPZDxzs0NORCgW1mgVyHLIb+S dIIT0BkpPSQINgGIFVkwKfTwIpjHfpKpXfUjTo4NXf8DES6NylCFnCcT8r37 DFou5oE95UoJlAhU1F672GjXeBubuq0X6R/Mv0nFx9xnENMF91UALMDDoDoP QoWKcYeKy6mMV1AZIjJSGUkqSJnVG8WypTcLrHYK/RJenzSeN4rdkzbnieCB EBpjjMU0xk4BZvxjGxsOBcOwUnKciqW/h4RTKgWwON3LPUZ3aqnCoAKp7C9p himyLvK4kxJG12Bkn/nX8AUJ7Ssft+JtikuJMgpjsdUmgEad6Vxqj8WlA6zn TwPcN7FA5wWw3nVKOsko6ggKBTf1QX9DdgnlaNlYlm6t3Wj1DmVBFJWEfk5a nabgJejPwGWHQ9pDwrsG34YCr5gLOvOrjDYljNgWuglcodS4i/ellV7EA21Y Tef7QAW+SVj4SOshLwW8WAwETHFxMQwQ8IcZBwzNdMrsh2Sc0Sq9VS1btGjP zHShXsV9FpxfQI+fja4xsDD1g0z1WHyYS92HvLpiRDP/r7wr/U0jyeLf81eU tB8WIgN9AH0oiQaMZ+zskGFD7M1otbKa7sbumEs0+BjNH7/v9171gWkcOxvN 7miRbOyuo1+9qnp31VM1EsdFdjUModnlns/HfXV+ShuU1iAcdFjiLhF50Dlh FOXauf/GkuR4JTxg8OgMG73AyRH4eHK1iCMu0EYpZleEogwA+lOxu7j0XL8h F90eA37LSPQZfmEptPhOIbAeF8SnyD4l8/L1eUsiQt9zqjGoSdQIYcYVeNym qXqLaB0HqfopmB2pi+UXAv5ajYLbWXKj3tzK/z8gfV8z/O3d4z4wmNOzQWbk 1W9jLM+ZLeOqdblyNpvlUEzZoNJItIhqXJ32zTwqLXGD2POw9/lyOLgcnFyM wTiIkw8ux/1LbDx64GTtcGOEYJ1Zb48ACtbr4EH8j6iBcJj1diFqhTyCupA9 Hvzy4aRZbHmRCD4dj1pnI1r6IiaIxMBegRGk480yXM5wEfjxcHSkzgf0i1pI uZ87ZPd8M0QOXNOzaHFBKkiPVLf9N3bGoCV1QFsnr1yWBFQtTvEwSa+xmrUj KFlE4iWqF9BDktB30mvZAwTQaMHtWsg7MpwmfCaalPks3iAxGnQmToQqERHw A7M6xaPHDbkYmfhdEYjM/kar23Zv1JQKeYNf/Dj21VD70xA2RPBz1ro8o2id Ec6e53Q70Vx8j/TDpbrnncWqG+Le9TFNH+CUZnpyv0YPG6m0Ys7zuKdsIRet WV+MY2LfxNipY9o2hvelsVFey/JanqcG4CKR6iO8ei25QFutu7u7Zho+zCKE RrV0UoFW3s31Zj571O8uubW7RG1hkG6ZZst0CJUR37sG1wbv2Ad10VTj4JaU yBua6DdpcPcD/TTTO7yxmV69Y7fNEheNsxcgYg7m8+XkofYm86PLyeyGFwbf 8E9IwbevEJ2RuFan47T4yyXe1UKg5wm6pBEdgWB7hm85vtP37a5/YgkVNl3x +9M0hjFjHaunsV2xg58jn1NEcub+E+CmEayx2HTLPmfQo4mJ5wig6HpO1yVh A/fnjjJrvHZCLNep0q4TX3183+5ID9ml0ElOUCG4yYg6anT6q/qLqV/GeSWo wzSeTRtwL/icniLOgNECOK3Shl6mh2rqbEazwm1xsCoEHXYokjC7X4l44L3V Dr2p0bbrh7AJtAnWVIDwkkAcMs+calNPtSmmBE2doWMSF7Y8nt2B4fcdv9vx Byd+b5Dx2Oo5Ev9Cgx3D/zdzZLSn7Y7pTuplyhPFWdeM+UrCk4ZpYihiXVGw IsalemfHzufPn9XJ2bjXuvi538KcMHE87feUXB2ODAG3pAtZTTcT+/F5k/UR JKHjet2W56jzGWnTlnQQcPH6XblNUdXP6v4DOtLxdbBAVAgpGNz2LHpLOoht tayOTU/6qfjUBH7zfxf+/tPwQ1MlPZUVUxVP7WlE7PSIxclZMk82iJXrDCcQ x9MbWNL0R+IP1QWHJ0hItXxwN/+MHpz0fup9OlHjT7bpWoaNTXtLvNExDWkp R2AUqRNwqzV6IeKIVOWn92F8lgVmZXzBsKpg734L7Gf94S7sgw8n44ZteKZj /CoFDPu41/tOsNtVsAd/YtjjPy3skfWt69204CfJ17ukG/kxmCfEAXLYSUIy d2EvIi8Pfp673iMrfD7sTGb9nm/6JNF8Cq6uiGz/nXoqhe80CbPxinRUIhHl JtbLm9gvb9J+fpP/AA29zQZ6SKTwWrZL4IwvBHuG44iT4YBu0p9JhAMEM9KK jINNJwebWl9rGh5san+taXSwabvUtJbPeR2ZZ0h/MIb9VqrNy2D3tbY8Pf3t iNQxJL5TSK5gdifJhtHFq1ALRCnsWHan07WNtqE6ptWAtqauo7s1EkuxaFMD sXfVsM9aWH4mTWQHn2UJ7oaTfHO6a76toQys9QJgbfMwsBO5j6RrHQaWKI2d wSot+OaUMjT2d4ImfDE0oRxwlJt/yiC1vxNI0YtBiuTUtNxc9d9WRZ13Z+Nf lNftGohnkxRYKcnUH89Gl6bnmWyGP2cCAhd1gqjTZPqQmVblOFwz19CPg8Vf NwpHktQj9RzWXNi+YZ6sOUeGSLhiOwiuVlc4lVfI7bewSapaWFfv4+lUnVLp nDYomujKPg3uPpmTIM2GCTEbAESYhtgYdLXKjQldzxhirHnb7SIPzNSut53i xbII3MyMp2K8yM096yCJDLgjUqjrcOaUZiVI1WKtrHJd8+m6HC6Jeh2foA7S Lcv6mbLA7gn2Rmih1aUOhGcTNzRJOGy6xEexkuNQV7GtrA4YJi3RZvdxldXZ 2eV8fq97cY12s71XpaNrSBXXftSLBnnLHsbpdhFK3JduVnvUol7GSOdpjLD7 7P1yC90K4ZZ9Nhnp+yf0khcrN9t95DQiouUbhtcyvZZBDLcjThrOrs22gsJZ 9fPFsDid0TSado3btGB8rsO+vJ3Fpf5XwRrLwYByS7vsQZ/lubcdF3qb47h1 9c/R8Xg0qh3RZq3/a7cR/BhOYcnVZ+ayA5ZNPjn3WjmO7XqWuulL1rcswp5K BJ6Ut+AiJc1bhRw4rm6n4GHbxXoVsh5PFGGa5g1qaX2nItxJYmZ+rfshxMrx Pe6iudwr4E4rntNr+ClQlKELtBLhGpUAw+8QRjugyaMdqJ7dHej4JT0mMipf a3ztj0tXqxiBNKwqWOcFB8AhIpZHEhPZLXn7gHuxcoL+lryAmeW+cjB7hcBO 9vA5+JnSUpE0hEWPulrlC69JyEHmPFDkMt8ov79c5/DCKbV+CmO0Baekb9zJ 8a0cK1mfKx0dAoRmzikhuxgcDhJTD4sGbSAR43SdJOVMca8zp+1O06IUhmu4 ykfhPEyCWh0v5D+1E3Udb4jMwNP2O3tqJRaDy/xi6M1XOvj9GJHTe4U4SD2h daE+UXnDqqjxu+BhFSbhUziYEAeTYS/EOA+/kS6snMzM6MtWjPv7+xcsp925 zK3HmMirJceeLNV6jv21u0ryQurgUSk3XsdYB5IJV6OXTwX8AVNdHpBGyFML c7N+0EOR8126w+soAPYWG8grLLQYkGA49+Ca6sFvSXyqlIuw9TGOToNNC/lH W7TcrmKLD5FNOWDMBHDDQWd8PoQnsutYVrdNHyNqT91gErme17a7Zuy4bbvT xrtx6D0TId/i4p3XSKiGNLnblI/I0Czo0H+5EoSGkK6CO1rr1/FshjyffwAd Plz1m5dzJg0+fxXvUT+ZfOnnuXScM0QqJGNM+caThCWwDJiclgpxLyrv0HgJ 5qoclciLIgne0+tEApqn0TJVXyYsLtu4ZJ4qE7f+Qj+4VmN2O28IWytQgLLD e5jfU8HU+M0VzwmWA7U7Fc8Z3ornNIKKpxhTVed6lFXQVD7VWHh6JgM+Dkoi F8TFmSq7j6E9Vc2Jls+y78tVuPdqXVQBVNHouSsMEgG7rgWej9vFQk6wihRI Is06WdHiRZpg2h25eEh1RyWiWaw9CPZVqTtfqygKd1mbmiyvqBofN0r9VzgR reS6kFIOaE7uPH5YhPp/JHaWf3Xiz11AdO5eHU1aKIn85r260Ms22nz3lczr vM3WIXs7VgkRO6+rO4niLPnvkbrmjNL3EhDyVlkmaTj648zncGyaHbfpdOZz 6o9D5RD+SlSocYcnOdp3OYmwkeKYbtcdwscumiQ6wjUwwQYJLZEpWSrQoHFp y5DKJdbyEF/AyfW0eT+fYWkEuABE6StP8tN/OEl9czVIwg2PGS0I98SZTnB2 KxYnEFyx4zBhZTwJX/0bUEsBAhcDFAAAAAgAil5SLWpvPtO9TgAAsAUBAAwA DQAAAAAAAQAAAP2BAAAAAGFuYWNkdW1wLnR4dFVUBQADZFiwPVV4AABQSwUG AAAAAAEAAQBHAAAA/E4AAAAA --=-6JLP6B02HK6tHPMR+8tQ-- From owner-linux-xfs@oss.sgi.com Fri Oct 18 18:46:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 18:46:12 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J1k9tG006527 for ; Fri, 18 Oct 2002 18:46:09 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9J1k3f20576 for ; Fri, 18 Oct 2002 21:46:03 -0400 Message-ID: <3DB0B95B.3194A852@splentec.com> Date: Fri, 18 Oct 2002 21:46:03 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: Re: No change: [Bug 182] New: Hitting the BUG() in filemap.c:843 (in unlock_page()) References: <3DB08276.E562BBF1@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Luben Tuikov wrote: > > Downloaded CVS version today (2002-10-18) at about 4:00 pm EDT. > Hitting the same BUG() with the configuration as described in > bug 182. > > Will give it a try... Raid chunk-size 4 doesn't BUG it, but the mounting process has to be allowd to sleep for 2-3 seconds after the fs was created and before the mount invoked. Else it sleeps on down() in pagebuf_iowait() indefinitely (called from xfs_bwrite())... Please see comment #2 in bugzilla on this bug. Anyone? -- Luben From owner-linux-xfs@oss.sgi.com Fri Oct 18 18:52:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 18:52:45 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J1qetG007410 for ; Fri, 18 Oct 2002 18:52:40 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J1qeVY007409 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 18:52:40 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J1qctI007392 for ; Fri, 18 Oct 2002 18:52:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J1dBqH006081; Fri, 18 Oct 2002 18:39:11 -0700 Date: Fri, 18 Oct 2002 18:39:11 -0700 Message-Id: <200210190139.g9J1dBqH006081@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 182] Hitting the BUG() in filemap.c:843 (in unlock_page()) X-Bugzilla-Reason: AssignedTo X-archive-position: 1100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=182 ------- Additional Comments From luben@splentec.com 2002-10-18 18:39 ------- When the RAID5 array is built with a chunk-size of 4 (KB) (page size) AND the mounting process is allowed to sleep at least 1 second after the creation of the xfs fs, then the BUG does NOT happen. If, OTOH, the mounting process is NOT allowed to sleep after creating the fs, then it sleeps on down() in pagebuf_iowait() indefinitely!!! (which was called by xfs_bwrite()) You can try this by using the scrips provided, by commenting and uncommenting the sleep 3 invocation before the mount. So, apparently the BUG is hit when the chunk size is greater than the page size. And the uninterruptible sleep when the xfs creator and the mounting process is the same one and not allowed to sleep in between. -- Luben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 19:21:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 19:21: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 g9J2LCtG009624 for ; Fri, 18 Oct 2002 19:21:12 -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 TAA02743 for ; Fri, 18 Oct 2002 19:21:11 -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 MAA12289 for ; Sat, 19 Oct 2002 12:19:55 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA13835 for linux-xfs@oss.sgi.com; Sat, 19 Oct 2002 12:19:54 +1000 (EST) Date: Sat, 19 Oct 2002 12:19:54 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: [Bug 185] New: Mount by LABEL does not work on whole disks. Message-ID: <20021019121954.B313655@wobbly.melbourne.sgi.com> References: <200210182153.g9ILrxrE018733@oss.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: <200210182153.g9ILrxrE018733@oss.sgi.com>; from bugzilla-daemon@oss.sgi.com on Fri, Oct 18, 2002 at 02:53:59PM -0700 X-archive-position: 1101 X-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 Austin, This bug needs to be sent to Andries (the util-linux maintainer) who sent mail the other day, not to us - it is not an XFS bug, but is rather a bug in the mount(2) program (part of the util-linux package). XFS and ext2/3 are just innocent bystanders here. cheers. On Fri, Oct 18, 2002 at 02:53:59PM -0700, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=185 > > Summary: Mount by LABEL does not work on whole disks. > Product: Linux XFS > Version: 1.1.x > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: normal > Priority: Medium > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: austin@coremetrics.com > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: 2.4.19-aa1 > > Where did the XFS code come from?: Part of the -AA tree. > > Description of Problem: > Mounting whole disks, rather than partitions, does not work by LABEL= > > > How Reproducible: > > Easily reproduceable. > > > Steps to Reproduce: > 1. Using a whole scsi disk, mkfs.xfs on it, > 2. Using xfs_admin -L somelabel /dev/sdN (where N is a-z) > 3. Add a LABEL=somelabel entry in /etc/fstab > 4. mount /somemountpoint > > This will fail. > > Actual Results: > Mount says the label does not exist. > > Expected Results: > Should be able to mount whole disks by label. > > Additional Information: > cat /proc/partitions sees the whole disks. Disks just don't have any partitions. > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 18 19:23:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 19:23:06 -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 g9J2N4tG010075 for ; Fri, 18 Oct 2002 19:23:04 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA82168; Fri, 18 Oct 2002 21:22:58 -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 VAA75867; Fri, 18 Oct 2002 21:22:58 -0500 (CDT) Date: Fri, 18 Oct 2002 21:19:11 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Florin Andrei cc: linux-xfs Subject: Re: v1.2 installer crash In-Reply-To: <1034989079.23919.1.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1102 X-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 Did you have LVM on this machine? Looks like it failed because "vgchange" failed... -Eric On 18 Oct 2002, Florin Andrei wrote: > The RH8.0 installer (1.2pre) crashed. I didn't do any of the "forbidden" > things mentioned in the README (text install, upgrade, use grub) yet it > crashed. > I attached the crash dump. > > The system is a SGI1200. > I cannot repeat the experiment, because the machine is not available > anymore. > > -- > Florin Andrei > > Writing a book on wireless security > is like writing a book on safe skydiving. > From owner-linux-xfs@oss.sgi.com Fri Oct 18 19:30:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 19:30:05 -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 g9J2U1tG011117 for ; Fri, 18 Oct 2002 19:30:02 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA05914; Fri, 18 Oct 2002 21:29:56 -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 VAA05132; Fri, 18 Oct 2002 21:29:55 -0500 (CDT) Date: Fri, 18 Oct 2002 21:26:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Luben Tuikov cc: linux-xfs Subject: Re: No change: [Bug 182] New: Hitting the BUG() in filemap.c:843 (in unlock_page()) In-Reply-To: <3DB08276.E562BBF1@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1103 X-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 Haven't had the time to look at it yet, it's in bugzilla, we're aware of it... feel free to add to the bug if you get more info. -Eric On Fri, 18 Oct 2002, Luben Tuikov wrote: > Downloaded CVS version today (2002-10-18) at about 4:00 pm EDT. > Hitting the same BUG() with the configuration as described in > bug 182. > > Will give it a try... > > Eric? > > -- > Luben > > From owner-linux-xfs@oss.sgi.com Fri Oct 18 19:52:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 19:52:43 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J2qetG013439 for ; Fri, 18 Oct 2002 19:52:40 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J2qeBH013435 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 19:52:40 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J2qctI013403 for ; Fri, 18 Oct 2002 19:52:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J2j2fk012887; Fri, 18 Oct 2002 19:45:02 -0700 Date: Fri, 18 Oct 2002 19:45:02 -0700 Message-Id: <200210190245.g9J2j2fk012887@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 ------- Additional Comments From sandeen@sgi.com 2002-10-18 19:45 ------- Can you reproduce this problem in a simpler setup? i.e. without having to install an lvm-root system? I'm not quite clear on the sequence of events that led to the shutdown. As I understand it, you were creating a tar file -from- the lvm snapshot filesystem? And the resulting tar file was being created on an lvm device as well? Please specify which LVM devices were "live," which were the snapshots, where they were mounted, and exactly which command led to the error. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 19:52:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 19:52:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J2qetG013438 for ; Fri, 18 Oct 2002 19:52:40 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J2qeNi013436 for linux-xfs@oss.sgi.com; Fri, 18 Oct 2002 19:52:40 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J2qctM013403 for ; Fri, 18 Oct 2002 19:52:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J2S5tY011020; Fri, 18 Oct 2002 19:28:05 -0700 Date: Fri, 18 Oct 2002 19:28:05 -0700 Message-Id: <200210190228.g9J2S5tY011020@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 185] Mount by LABEL does not work on whole disks. X-Bugzilla-Reason: AssignedTo X-archive-position: 1105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=185 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From sandeen@sgi.com 2002-10-18 19:28 ------- As Nathan says, This bug needs to be sent to Andries (the util-linux maintainer) who sent mail the other day, not to us - it is not an XFS bug, but is rather a bug in the mount(2) program (part of the util-linux package). XFS and ext2/3 are just innocent bystanders here. Marking INVALID, this is not an xfs bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 18 21:31:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Oct 2002 21:31:16 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J4VAtG022074 for ; Fri, 18 Oct 2002 21:31:10 -0700 Received: (qmail 670 invoked by uid 500); 19 Oct 2002 04:30:51 -0000 Subject: Re: [Bug 185] New: Mount by LABEL does not work on whole disks. From: Austin Gonyou To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021019121954.B313655@wobbly.melbourne.sgi.com> References: <20021019121954.B313655@wobbly.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7/idzaRdjLNQ8fjcmeQ6" Organization: Coremetrics, Inc. Message-Id: <1035001850.647.1.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2.99 (Preview Release) Date: 18 Oct 2002 23:30:51 -0500 X-archive-position: 1106 X-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 --=-7/idzaRdjLNQ8fjcmeQ6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-10-18 at 21:19, Nathan Scott wrote: > Austin, >=20 > This bug needs to be sent to Andries (the util-linux maintainer) who > sent > mail the other day, not to us - it is not an XFS bug, but is rather a > bug > in the mount(2) program (part of the util-linux package). XFS and > ext2/3 > are just innocent bystanders here. Understood. I thought you told me to submit it as a bug for XFS though? Did I misunderstand? > cheers. >=20 > On Fri, Oct 18, 2002 at 02:53:59PM -0700, bugzilla-daemon@oss.sgi.com > wrote: > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=3D185 > >=20 > > Summary: Mount by LABEL does not work on whole disks. > > Product: Linux XFS > > Version: 1.1.x > > Platform: IA32 > > OS/Version: Linux > > Status: NEW > > Severity: normal > > Priority: Medium > > Component: XFS kernel code > > AssignedTo: xfs-master@oss.sgi.com > > ReportedBy: austin@coremetrics.com > >=20 > >=20 > > If this is a userspace bug, what version of the package are you > using: > >=20 > > What kernel are you using: 2.4.19-aa1 > >=20 > > Where did the XFS code come from?: Part of the -AA tree. > >=20 > > Description of Problem: > > Mounting whole disks, rather than partitions, does not work by > LABEL=3D > >=20 > >=20 > > How Reproducible: > >=20 > > Easily reproduceable. > >=20 > >=20 > > Steps to Reproduce: > > 1. Using a whole scsi disk, mkfs.xfs on it,=20 > > 2. Using xfs_admin -L somelabel /dev/sdN (where N is a-z) > > 3. Add a LABEL=3Dsomelabel entry in /etc/fstab > > 4. mount /somemountpoint > >=20 > > This will fail. > >=20 > > Actual Results: > > Mount says the label does not exist. > >=20 > > Expected Results: > > Should be able to mount whole disks by label. > >=20 > > Additional Information: > > cat /proc/partitions sees the whole disks. Disks just don't have any > partitions. > >=20 > >=20 > >=20 > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > >=20 > >=20 >=20 > --=20 > Nathan --=20 Austin Gonyou Coremetrics, Inc. --=-7/idzaRdjLNQ8fjcmeQ6 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 iD8DBQA9sN/694g6ZVmFMoIRAvteAJ9MXeM2IBHTRIVQ3jjKjaX2VvhXEQCfQFk5 lcTgMBmOY+64CkF5T5zPBAk= =QR6Y -----END PGP SIGNATURE----- --=-7/idzaRdjLNQ8fjcmeQ6-- From owner-linux-xfs@oss.sgi.com Sat Oct 19 00:38:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 00:38:29 -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 g9J7c9tG004301 for ; Sat, 19 Oct 2002 00:38:09 -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 AAA09656 for ; Sat, 19 Oct 2002 00:38:07 -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 RAA13657; Sat, 19 Oct 2002 17:36:50 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA15036; Sat, 19 Oct 2002 17:36:49 +1000 (EST) Date: Sat, 19 Oct 2002 17:36:49 +1000 From: Nathan Scott To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 185] New: Mount by LABEL does not work on whole disks. Message-ID: <20021019173648.A314255@wobbly.melbourne.sgi.com> References: <20021019121954.B313655@wobbly.melbourne.sgi.com> <1035001850.647.1.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1035001850.647.1.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Fri, Oct 18, 2002 at 11:30:51PM -0500 X-archive-position: 1107 X-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 Fri, Oct 18, 2002 at 11:30:51PM -0500, Austin Gonyou wrote: > ... > Understood. I thought you told me to submit it as a bug for XFS though? > Did I misunderstand? > Yeah, I should have been clearer - Andries wanted someone to send him a bug report saying why this is needed (seems obvious to me, but I think thats what he was after). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Oct 19 01:21:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 01:21:52 -0700 (PDT) Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J8LmtG008104 for ; Sat, 19 Oct 2002 01:21:49 -0700 Received: from online.no (81.80-202-103.nextgentel.com [80.202.103.81]) by mail.broadpark.no (Postfix) with ESMTP id 7A2897E77 for ; Sat, 19 Oct 2002 10:21:41 +0200 (MEST) Message-ID: <3DB11615.E6A50E18@online.no> Date: Sat, 19 Oct 2002 10:21:41 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18-17.8.0_XFScustom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: XFS for new update redhat kernel 2.4.18-17.8 References: <20021018172002.GA7770@morpheus.matrix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs I applied the patch from 2.4.18-14XFS and they applied cleanly, but kdb does not work or rather does not compile.. There are a redhat kernel with xfs at http://people.redhat.com/arjanv/2.5/. From owner-linux-xfs@oss.sgi.com Sat Oct 19 01:36:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 01:36:14 -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 g9J8aBtG009528 for ; Sat, 19 Oct 2002 01:36:12 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AD98B2FA71 for ; Sat, 19 Oct 2002 01:36:11 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 0CCE92FA71 for ; Sat, 19 Oct 2002 01:36:11 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 986ED1967B for ; Sat, 19 Oct 2002 01:36:00 -0700 (PDT) Subject: Re: v1.2 installer crash From: Florin Andrei To: linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Oct 2002 01:36:00 -0700 Message-Id: <1035016560.1787.1.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1109 X-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 Just a plain SGI1200, with 4xSCSI. I'm not sure what vgchange means. BTW, the plain RH8.0 installer worked without any problems. On Fri, 2002-10-18 at 19:19, Eric Sandeen wrote: > Did you have LVM on this machine? > > Looks like it failed because "vgchange" failed... > > -Eric > > On 18 Oct 2002, Florin Andrei wrote: > > > The RH8.0 installer (1.2pre) crashed. I didn't do any of the "forbidden" > > things mentioned in the README (text install, upgrade, use grub) yet it > > crashed. > > I attached the crash dump. > > > > The system is a SGI1200. > > I cannot repeat the experiment, because the machine is not available > > anymore. > > > > -- > > Florin Andrei > > > > Writing a book on wireless security > > is like writing a book on safe skydiving. > > > > -- Florin Andrei Writing a book on wireless security is like writing a book on safe skydiving. From owner-linux-xfs@oss.sgi.com Sat Oct 19 02:18:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 02:18:49 -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 g9J9IitG012403 for ; Sat, 19 Oct 2002 02:18:45 -0700 Received: (qmail 13927 invoked from network); 19 Oct 2002 09:18:42 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Oct 2002 09:18:42 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id C878E300B29; Sat, 19 Oct 2002 19:18:39 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 299F7108F; Sat, 19 Oct 2002 19:18:39 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Knut J Bjuland Cc: linux-xfs Subject: Re: XFS for new update redhat kernel 2.4.18-17.8 In-reply-to: Your message of "Sat, 19 Oct 2002 10:21:41 +0200." <3DB11615.E6A50E18@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Oct 2002 19:18:33 +1000 Message-ID: <9298.1035019113@ocs3.intra.ocs.com.au> X-archive-position: 1110 X-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 Sat, 19 Oct 2002 10:21:41 +0200, Knut J Bjuland wrote: >I applied the patch from 2.4.18-14XFS and they applied cleanly, but kdb does >not work or rather does not compile.. RedHat apply patches in the same area that kdb does, it is not unusual for kdb to either not patch or fail to compile over RH patches. kdb only tracks standard Marcelo/Linus kernels, not distributors. My standard answer is ... ask for a kdb patch that fits their kernel. From owner-linux-xfs@oss.sgi.com Sat Oct 19 02:52:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 02:52:43 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J9qftG016780 for ; Sat, 19 Oct 2002 02:52:41 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J9qfkW016779 for linux-xfs@oss.sgi.com; Sat, 19 Oct 2002 02:52:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9J9qdtI016765 for ; Sat, 19 Oct 2002 02:52:39 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9J9ZNUm014201; Sat, 19 Oct 2002 02:35:23 -0700 Date: Sat, 19 Oct 2002 02:35:23 -0700 Message-Id: <200210190935.g9J9ZNUm014201@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 ------- Additional Comments From sgi@debian.franken.de 2002-10-19 02:35 ------- What I did was like this: lvcreate -n root-snap -L 512m /dev/master/root-xfs lvcreate -n var-snap -L 512m /dev/master/var-xfs lvcreate -n home-snap -L 512m /dev/master/home-xfs mkdir /snap mount -o nouuid,ro /dev/master/root-snap /snap mount -o nouuid,ro /dev/master/var-snap /snap/var moint -o nouuid,ro /dev/master/home-snap /snap/home cd /snap tar cvfzp /seperated-filesystem-on-a-partition-with-ext3/backup.tar.gz * ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 19 03:17:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 03:17:03 -0700 (PDT) Received: from paddington.snp.org (postfix@exiled.albanach.com [212.135.138.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JAGttG019258 for ; Sat, 19 Oct 2002 03:17:00 -0700 Received: from localhost (localhost [127.0.0.1]) by paddington.snp.org (Postfix ESMTP paddington.snp.org) with ESMTP id 113D6285B7 for ; Sat, 19 Oct 2002 11:14:31 +0100 (BST) Received: from snp.org (localhost [127.0.0.1]) by paddington.snp.org (Postfix ESMTP paddington.snp.org) with SMTP id 40B9B285AD for ; Sat, 19 Oct 2002 11:14:30 +0100 (BST) Received: from modem-218.blotto.dialup.pol.co.uk ([62.25.144.218]) (SquirrelMail authenticated user kieran) by secure.albanach.com with HTTP; Sat, 19 Oct 2002 11:14:30 +0100 (BST) Message-ID: <62832.62.25.144.218.1035022470.squirrel@secure.albanach.com> Date: Sat, 19 Oct 2002 11:14:30 +0100 (BST) Subject: XFS/Alpha Blocksize query From: "kieran fulke" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 1112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-xfs I recall reading on the list somewhere, someone mentioning that XFS and other filesystems on alpha-linux would use a blocksize of 8k, given the pagesize being the same. having just recently moved / on my alpha over to XFS, I noticed this oddity: kieran@hysteria kieran $ xfs_info / meta-data=/ isize=256 agcount=3, agsize=732966 blks data = bsize=4096 blocks=2198896, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=6144 version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I created that fs with "mkfs.xfs -f -d agcount=3 -l size=24m -L / /dev/sda2" intentionally not specifying a blocksize, in any of the options, expecting it to use the native 8k pagesize, but it didnt.this isnt a problem in any way, the fs works fine, as to the utilities (xfsdump, fsr et al) .. I'm just curious. here's /proc/cpuinfo as well, just for good measure: kieran@hysteria kieran $ cat /proc/cpuinfo cpu : Alpha cpu model : EV56 cpu variation : 7 cpu revision : 0 cpu serial number : system type : EB164 system variation : LX164 system revision : 0 system serial number : cycle frequency [Hz] : 600000000 timer frequency [Hz] : 1024.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS : 1191.08 kernel unaligned acc : 50244 (pc=fffffc000090c694,va=fffffc001e4c806c) user unaligned acc : 0 (pc=0,va=0) platform string : Digital AlphaPC 164LX 599 MHz regards, From owner-linux-xfs@oss.sgi.com Sat Oct 19 07:44:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 07:44:27 -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 g9JEiJtG006532 for ; Sat, 19 Oct 2002 07:44:19 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA28175; Sat, 19 Oct 2002 09:44:14 -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 JAA87382; Sat, 19 Oct 2002 09:44:13 -0500 (CDT) Date: Sat, 19 Oct 2002 09:40:21 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: kieran fulke cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Alpha Blocksize query In-Reply-To: <62832.62.25.144.218.1035022470.squirrel@secure.albanach.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1113 X-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 Kieran - Originally, XFS only supported page-sized filesystem block sizes. However, that restriction is now gone, and block sizes < page size also are supported. So, originally, mkfs.xfs would make page-sized blocks by default. Now that other block sizes are supported as well, the default is 4k. -Eric On Sat, 19 Oct 2002, kieran fulke wrote: > I recall reading on the list somewhere, someone mentioning that XFS and > other filesystems on alpha-linux would use a blocksize of 8k, given the > pagesize being the same. having just recently moved / on my alpha over to > XFS, I noticed this oddity: (4k blocksize) > I created that fs with "mkfs.xfs -f -d agcount=3 -l size=24m -L / > /dev/sda2" intentionally not specifying a blocksize, in any of the > options, expecting it to use the native 8k pagesize, but it didnt.this isnt a problem in any way, the fs works fine, as to the utilities > (xfsdump, fsr et al) .. I'm just curious. From owner-linux-xfs@oss.sgi.com Sat Oct 19 08:12:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 08:12:50 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-25.uc.nombres.ttd.es [213.99.177.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JFChtG009273 for ; Sat, 19 Oct 2002 08:12:44 -0700 Received: (qmail 14229 invoked by uid 1000); 19 Oct 2002 15:13:35 -0000 From: yoros@wanadoo.es Date: Sat, 19 Oct 2002 17:13:35 +0200 To: linux-xfs Subject: About pagesize Message-ID: <20021019151335.GA14189@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Sorry for my question but I haven't found the answer. There are a few mails about block size. I know that ReiserFS have fixed sector size and it puts small files and small pieces in the same block. What things do XFS with bocks?. I know that XFS have variable block-size, but I don't know anything about how XFS uses it. I hope that my expressions were understandable. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9sXafWIvihXTx06wRAhDdAJ4lAb4b+MIGy9jzOrsqCjhSsqPpGACeNQ3W n8rgqjBkasonvExr3D9lS9Q= =dwPS -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-linux-xfs@oss.sgi.com Sat Oct 19 09:17:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 09:17:31 -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 g9JGHPtG013948 for ; Sat, 19 Oct 2002 09:17:26 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 182wHz-0003Oq-00; Sat, 19 Oct 2002 17:17:23 +0100 Date: Sat, 19 Oct 2002 17:17:23 +0100 From: Christoph Hellwig To: Knut J Bjuland Cc: linux-xfs Subject: Re: XFS for new update redhat kernel 2.4.18-17.8 Message-ID: <20021019171723.A13066@infradead.org> References: <20021018172002.GA7770@morpheus.matrix.com> <3DB11615.E6A50E18@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DB11615.E6A50E18@online.no>; from knutjbj@online.no on Sat, Oct 19, 2002 at 10:21:41AM +0200 X-archive-position: 1115 X-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 19, 2002 at 10:21:41AM +0200, Knut J Bjuland wrote: > I applied the patch from 2.4.18-14XFS and they applied cleanly, but kdb does > not work or rather does not compile.. There are a redhat kernel with xfs at > http://people.redhat.com/arjanv/2.5/. I'll try to get it fixed next week. From owner-linux-xfs@oss.sgi.com Sat Oct 19 11:32:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 11:32:13 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm6.tiscalinet.be [212.35.2.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JIW5tG024870 for ; Sat, 19 Oct 2002 11:32:06 -0700 Received: from [62.235.70.151] (helo=freebel.net) by smtp-out.tiscali.be with esmtp (Tiscalinet) id 182yOH-0006sF-00; Sat, 19 Oct 2002 20:32:01 +0200 Message-ID: <3DB1B494.8000909@freebel.net> Date: Sat, 19 Oct 2002 19:37:56 +0000 From: Joel Soete 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: Stephen Lord CC: jsoe0708@tiscali.be, linux-xfs@oss.sgi.com Subject: Re: XFS (CVS release) problem to compile on hppa References: <3DA56CAE0000313D@ocpmta8.be.tiscali.com> <1034948248.1421.25.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joel.soete@freebel.net Precedence: bulk X-list: linux-xfs Hi Stephen, I well get new cvs release dated 20021019 and I well reach to obtain a bootable kernel :-). Asap I will build corresponding cmd and test a xfs fs. Thanks again for attention and advise, Joel Stephen Lord wrote: > On Fri, 2002-10-18 at 09:30, jsoe0708@tiscali.be wrote: > > >>But the build failled because: >>"../xfs_bmap_btree.h:661:35: "0" may not appear in macro parameter list" >> >>and in this header I found: >>"... >>#else >>... >>#define xfs_bmbt_disk_set_allf(r, 0, b, c, v) \ >> xfs_bmbt_set_allf(r, 0, b, c, v) >>#endif >>... >>" > > > This should be fixed in the latest cvs code - if it is not our > cvs updates have stalled again. > > Steve > > > > From owner-linux-xfs@oss.sgi.com Sat Oct 19 13:13:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 13:13:46 -0700 (PDT) Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JKDetG001605 for ; Sat, 19 Oct 2002 13:13:41 -0700 Received: from [217.228.38.190] (helo=[192.168.1.110]) by smtp.web.de with smtp (WEB.DE(Exim) 4.75 #2) id 182zyY-0001iq-00 for linux-xfs@oss.sgi.com; Sat, 19 Oct 2002 22:13:34 +0200 From: Tom Subject: How to find out version of formated XFS Partition To: linux-xfs@oss.sgi.com Date: Sat, 19 Oct 2002 22:00:11 +0200 Lines: 7 Message-ID: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: Kaufman Mail Warrior 3,61 Final X-archive-position: 1117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t_wulf@web.de Precedence: bulk X-list: linux-xfs Hi, how to find out which version an already formated XFS Partition does have? Or is a XFS Partition independent from the Release Packages (1.0, 1.01, 1.02, 1.1, soon 1.2, etc....) ? Thanks and Bye, Tom From owner-linux-xfs@oss.sgi.com Sat Oct 19 13:52:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 13:52: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 g9JKqJtG005113 for ; Sat, 19 Oct 2002 13:52:19 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1768C1ECBD4; Sat, 19 Oct 2002 13:52:19 -0700 (PDT) Date: Sat, 19 Oct 2002 13:52:19 -0700 From: Chris Wedgwood To: Tom Cc: linux-xfs@oss.sgi.com Subject: Re: How to find out version of formated XFS Partition Message-ID: <20021019205219.GA32504@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: 1118 X-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 19, 2002 at 10:00:11PM +0200, Tom wrote: > how to find out which version an already formated XFS Partition does > have? Or is a XFS Partition independent from the Release Packages > (1.0, 1.01, 1.02, 1.1, soon 1.2, etc....) ? The on-disk format has not changed. It's possible some older kernels had bugs produce logs which won't replay on newer kernels but not very likely (and if this is the case, it's pretty easy to get around). --cw From owner-linux-xfs@oss.sgi.com Sat Oct 19 14:04:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 14:04:56 -0700 (PDT) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JL4otG006448 for ; Sat, 19 Oct 2002 14:04:51 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id 3F7515722F; Sat, 19 Oct 2002 23:04:44 +0200 (CEST) Received: from sirius.quickstep.oche.de (sirius.quickstep.oche.de [192.168.48.4]) by foehn.quickstep.oche.de (8.9.3/8.6.12) with ESMTP id WAA07692 for ; Sat, 19 Oct 2002 22:57:24 +0200 (CEST) Received: (from martin@localhost) by sirius.quickstep.oche.de (SGI-8.9.3/8.9.3) id WAA05071; Sat, 19 Oct 2002 22:57:23 +0200 (CEST) Date: Sat, 19 Oct 2002 22:57:23 +0200 (CEST) Message-Id: <200210192057.WAA05071@sirius.quickstep.oche.de> From: Martin Spott To: linux-xfs Subject: Re: Qlogic 2300 and XFS X-Newsgroups: list.linux-xfs In-Reply-To: User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (IRIX64/6.5 (IP30)) X-archive-position: 1119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs > Anyone here using Qlogic 2300Fs and XFS with an uptime of > 30 days on > 5.38.x drivers or > 15 days on 6.0x drivers? I've experienced _numerous_ crashes on SMP machines (ASUS CUR-DLS) after _very_ few days uptime with QLA2300. I've used the drivers included in kernel 2.4.18 (with xfs-1.1) and 2.4.14 without XFS. The crashes disappeared after disabling one CPU. I never experienced these crashes with QLA2200 .... What are you aiming at ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sat Oct 19 14:54:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 14:54:35 -0700 (PDT) Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLsWtG012766 for ; Sat, 19 Oct 2002 14:54:33 -0700 Received: (qmail 23967 invoked by uid 0); 19 Oct 2002 21:54:26 -0000 Received: from bc0b2.pppool.de (213.7.192.178) by mail.gmx.net (mp018-rz3) with SMTP; 19 Oct 2002 21:54:26 -0000 From: "Gerold J. Wucherpfennig" To: linux-xfs@oss.sgi.com Subject: RH8 installer? Date: Sat, 19 Oct 2002 23:59:51 +0200 User-Agent: KMail/1.4.7 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200210192359.56874.gjwucherpfennig@gmx.net> X-archive-position: 1120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gjwucherpfennig@gmx.net Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Will there be a Red Hat 8 installer for XFS? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9sdXX53zyw+ONqrERAqXNAJwKfiQhDQithuXHaXiaKzANsKvZXACfZaY1 acbeTR9p1Pv6udcb/wVHexo= =aUab -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Oct 19 15:36:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 15:36:11 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JMa6tG017473 for ; Sat, 19 Oct 2002 15:36:07 -0700 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 555854B7EA1; Sat, 19 Oct 2002 17:36:12 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id BB4F24B7E9B; Sat, 19 Oct 2002 17:36:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id A74FAC026C7; Sat, 19 Oct 2002 17:36:10 -0500 (EST) Date: Sat, 19 Oct 2002 17:36:09 -0500 (EST) From: Mike Burger To: "Gerold J. Wucherpfennig" Cc: linux-xfs@oss.sgi.com Subject: Re: RH8 installer? In-Reply-To: <200210192359.56874.gjwucherpfennig@gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Not according to the text files posted with the 7.3 installer...unless someone out in the wild wants to put one together. On Sat, 19 Oct 2002, Gerold J. Wucherpfennig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Will there be a Red Hat 8 installer for XFS? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9sdXX53zyw+ONqrERAqXNAJwKfiQhDQithuXHaXiaKzANsKvZXACfZaY1 > acbeTR9p1Pv6udcb/wVHexo= > =aUab > -----END PGP SIGNATURE----- > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 From owner-linux-xfs@oss.sgi.com Sat Oct 19 17:15:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 17:15:58 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9K0FqtG026731 for ; Sat, 19 Oct 2002 17:15:53 -0700 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 07E434B7E9F; Sat, 19 Oct 2002 19:15:59 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 878F04B7E9B; Sat, 19 Oct 2002 19:15:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7936CC026C3; Sat, 19 Oct 2002 19:15:57 -0500 (EST) Date: Sat, 19 Oct 2002 19:15:56 -0500 (EST) From: Mike Burger To: "Gerold J. Wucherpfennig" Cc: linux-xfs@oss.sgi.com Subject: Re: RH8 installer? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs It would appear that I was incorrect. On Sat, 19 Oct 2002, Mike Burger wrote: > Not according to the text files posted with the 7.3 installer...unless > someone out in the wild wants to put one together. > > On Sat, 19 Oct 2002, Gerold J. Wucherpfennig wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Will there be a Red Hat 8 installer for XFS? > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.7 (GNU/Linux) > > > > iD8DBQE9sdXX53zyw+ONqrERAqXNAJwKfiQhDQithuXHaXiaKzANsKvZXACfZaY1 > > acbeTR9p1Pv6udcb/wVHexo= > > =aUab > > -----END PGP SIGNATURE----- > > > > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 From owner-linux-xfs@oss.sgi.com Sat Oct 19 22:47:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 19 Oct 2002 22:47:54 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9K5lltG018065 for ; Sat, 19 Oct 2002 22:47:48 -0700 Received: from online.no (81.80-202-103.nextgentel.com [80.202.103.81]) by mail.broadpark.no (Postfix) with ESMTP id 03D3F7D69; Sun, 20 Oct 2002 07:30:37 +0200 (MEST) Message-ID: <3DB23F7D.7DCC5831@online.no> Date: Sun, 20 Oct 2002 07:30:37 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18-17.8.0_XFScustom i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger Cc: "Gerold J. Wucherpfennig" , linux-xfs@oss.sgi.com Subject: Re: RH8 installer? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs There are a prelesease installer for Redhat 8.0 at sgi. Mike Burger wrote: > It would appear that I was incorrect. > > On Sat, 19 Oct 2002, Mike Burger wrote: > > > Not according to the text files posted with the 7.3 installer...unless > > someone out in the wild wants to put one together. > > > > On Sat, 19 Oct 2002, Gerold J. Wucherpfennig wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Will there be a Red Hat 8 installer for XFS? > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.0.7 (GNU/Linux) > > > > > > iD8DBQE9sdXX53zyw+ONqrERAqXNAJwKfiQhDQithuXHaXiaKzANsKvZXACfZaY1 > > > acbeTR9p1Pv6udcb/wVHexo= > > > =aUab > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > -- > Mike Burger > http://www.bubbanfriends.org > > Visit the Dog Pound II BBS > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 From owner-linux-xfs@oss.sgi.com Sun Oct 20 05:59:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 05:59: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 g9KCxqtG022602 for ; Sun, 20 Oct 2002 05:59:52 -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 FAA00104 for ; Sun, 20 Oct 2002 05:59:51 -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 WAA30825; Sun, 20 Oct 2002 22:58:33 +1000 (EST) Date: Sun, 20 Oct 2002 22:58:33 +1000 (EST) From: Nathan Scott Message-Id: <200210201258.WAA30825@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr/acl packaging X-archive-position: 1124 X-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 Change to the package name for the ACL and attr development packages. Date: Sun Oct 20 05:55:55 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:130562a cmd/acl/VERSION - 1.37 cmd/acl/doc/CHANGES - 1.44 cmd/acl/build/rpm/acl.spec.in - 1.8 cmd/acl/debian/control - 1.8 cmd/acl/debian/Makefile - 1.9 cmd/acl/debian/changelog - 1.31 cmd/acl/debian/rules - 1.10 cmd/attr/VERSION - 1.24 cmd/attr/doc/CHANGES - 1.31 cmd/attr/build/rpm/attr.spec.in - 1.10 cmd/attr/debian/control - 1.7 cmd/attr/debian/Makefile - 1.8 cmd/attr/debian/changelog - 1.25 cmd/attr/debian/rules - 1.8 - Change the devel .rpm and .deb package names so that they use a lib prefix. Several packaging changes related to this to ensure upgrades work correctly and dependency information isn't lost. cmd/xfsprogs/libxfs/init.c - 1.22 - Correct handling of realtime devices which was recently busted. cmd/xfsdump/configure.in - 1.24 - Minor changes to error messages on configure failure. From owner-linux-xfs@oss.sgi.com Sun Oct 20 12:22:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 12:22:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9KJMltG016961 for ; Sun, 20 Oct 2002 12:22:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9KJMlr4016960 for linux-xfs@oss.sgi.com; Sun, 20 Oct 2002 12:22:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9KJMjtG016945 for ; Sun, 20 Oct 2002 12:22:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9KJ2ouc015569; Sun, 20 Oct 2002 12:02:50 -0700 Date: Sun, 20 Oct 2002 12:02:50 -0700 Message-Id: <200210201902.g9KJ2ouc015569@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] New: xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 Summary: xfs_force_shutdown on a lvm device Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: christian.guggenberger@physik.uni-regensburg.de What kernel are you using: 2.4.19 SGI XFS CVS-10/08/02:15 with acls, quota, no debug. + e1000 Intel Network driver, version 4.3.15 Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS, compiled on a debian woody machine. Description of Problem: Recently, our nfs-server (Dell Poweredge 2500, 2x1.4GHz, 2GB Ram, 2 external ide2scsi Raid-5), called xfs_force_shutdown. This machine acts as nfsserver only. xfs_force_shutdown(lvm(58,1),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xf8c06de9 Corruption of in-memory data detected. Shutting down filesystem: lvm(58,1) Please umount the filesystem, and rectify the problem(s) That's all what I can see in my logs. lvm(58,1) is ~400GB and it's part of a ~800GB external ide2scsi HW Raid5. This logical volume was created with lvm-1.0.4-4 userspace tools. umounting that device and mounting again ended up in clean xfs-filesystem again. This was the first filesystem problem since the server went in production 10 weeks ago. How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Oct 20 12:43:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 12:43:06 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-25.uc.nombres.ttd.es [213.99.177.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KJgktG018722 for ; Sun, 20 Oct 2002 12:42:48 -0700 Received: (qmail 25392 invoked by uid 1000); 20 Oct 2002 19:43:40 -0000 From: yoros@wanadoo.es Date: Sun, 20 Oct 2002 21:43:40 +0200 To: linux-xfs Subject: New experience with xfsdump Message-ID: <20021020194339.GA25380@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry for whom are registered in bugzilla. ------ I have another experience with xfsdump. I said that xfsdump fails when excluding files that have SGI_XFSDUMP_SKIP_FILE attribute set, but the action is near of xfsdump execution. Now, I have seen another situation: 1. I do a level 0 dump with -e option and with a lot of excluded files. 2. I unset SGI_XFSDUMP_SKIP_FILE attribute. 3. Time goes and files are created. 4. I set SGI_XFSDUMP_SKIP_FILE attribute to all files (new and old files). 5. I try to do a level 1 dump and I see that the new files created since the level 0 dump are selected, even if they have SGI_XFSDUMP_SKIP_FILE attribute set, 6. I try to do a level 1 dump again, and all SGI_XFSDUMP_SKIP_FILE are excluded. I think these points are very expressive, if somebody has any question, please post it to linux-xfs mailling list. ------ Cheers, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9swdrWIvihXTx06wRAh7FAKCJuMSZ5+5O6uNthijZUDi2BwLHngCfTls7 Wh0YZflCdt/rg3tDINzzzI8= =mKES -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-linux-xfs@oss.sgi.com Sun Oct 20 12:52:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 12:52:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9KJqltG019734 for ; Sun, 20 Oct 2002 12:52:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9KJqlBq019733 for linux-xfs@oss.sgi.com; Sun, 20 Oct 2002 12:52:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9KJqjtG019719 for ; Sun, 20 Oct 2002 12:52:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9KJc7EX018440; Sun, 20 Oct 2002 12:38:07 -0700 Date: Sun, 20 Oct 2002 12:38:07 -0700 Message-Id: <200210201938.g9KJc7EX018440@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 180] xfsdump is wrong with -e and files created since last dump X-Bugzilla-Reason: AssignedTo X-archive-position: 1127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=180 ------- Additional Comments From yoros@wanadoo.es 2002-10-20 12:38 ------- I have another experience with xfsdump. I said that xfsdump fails when excluding files that have SGI_XFSDUMP_SKIP_FILE attribute set, but the action is near of xfsdump execution. Now, I have seen another situation: 1. I do a level 0 dump with -e option and with a lot of excluded files. 2. I unset SGI_XFSDUMP_SKIP_FILE attribute. 3. Time goes and files are created. 4. I set SGI_XFSDUMP_SKIP_FILE attribute to all files (new and old files). 5. I try to do a level 1 dump and I see that the new files created since the level 0 dump are selected, even if they have SGI_XFSDUMP_SKIP_FILE attribute set, 6. I try to do a level 1 dump again, and all SGI_XFSDUMP_SKIP_FILE are excluded. I think these points are very expressive, if somebody has any question, please post it to linux-xfs mailling list. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Oct 20 19:22:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 19:22:55 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9L2MntG013484 for ; Sun, 20 Oct 2002 19:22:49 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9L2MmVM013483 for linux-xfs@oss.sgi.com; Sun, 20 Oct 2002 19:22:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9L2MltI013467 for ; Sun, 20 Oct 2002 19:22:47 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9L27Wqi012479; Sun, 20 Oct 2002 19:07:32 -0700 Date: Sun, 20 Oct 2002 19:07:32 -0700 Message-Id: <200210210207.g9L27Wqi012479@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 c.pascoe@itee.uq.edu.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c.pascoe@itee.uq.edu.au ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-20 19:07 ------- I also experienced the shutdown filesystem described in this job and also previously by Ian Hardy (difference being that Ian's was on a MD device), after experiencing an unclean shutdown. I have the same configuration (software wise) as described in this message. My machine is also serving up files via NFS as per this job. It also has ECC memory and has reported no ECC errors. History before my crashes: * System had been running kernel from 24/5/2002 plus critical fixes merged by me (booted on 12/6/2002) * On the evening of 2/10/2002 AEST I ran a firmware update on the machine the machine crashed (whilst it was live, in preparation for restarting it - I've done this several times before successfully though!) * The machine restarted into the kernel that I had built and booted on an identical box, compiled from CVS taken on 2/10/2002 AEST. This kernel was CVS up to either modid 2.4.x-xfs:slinx:128691a or possibly modid 2.4.x-xfs:slinx:128671a. The machine performed recovery on the filesystem at this time successfully. * The next day I realised I hadn't merged the LVM 1.0.5 and VFS-lock code in, so pulled in the changes from CVS that were made overnight and added the LVM patches. At this point in time, the kernel was CVS to modid 2.4.x-xfs:slinx:128918a plus LVM 1.0.5 and LVM vfs-lock patches. I built this kernel and put it in place to boot; did not test it on another machine. * I then managed to lock up a RAID controller whilst trying to create a new container and the machine restarted itself as a result of this. (No, I am not having a good week!!!). I believe all commands to the array from this time were abandoned. * The machine restarted, and did NOT report that it performed recovery on the disk. It completed the boot process, then eight minutes later I have recorded on the serial console: xfs_force_shutdown(lvm(58,0),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xf89dcac5 Corruption of in-memory data detected. Shutting down filesystem: lvm(58,0) At this point, the watchdog on the machine restarted it again, it booted the kernel that had been running forever (24/5/2002+), performed recovery and everything has been fine since. Since this failure, I have taken the filesystem offline and run xfs_check across it - it found no problems with the on-disk data. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Oct 20 21:25:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 21:25: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 g9L4PTtG022386 for ; Sun, 20 Oct 2002 21:25:29 -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 VAA09743 for ; Sun, 20 Oct 2002 21:25:28 -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 OAA72194 for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 14:24:11 +1000 (EST) Date: Mon, 21 Oct 2002 14:24:11 +1000 (EST) From: Nathan Scott Message-Id: <200210210424.OAA72194@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - realtime mount fix X-archive-position: 1129 X-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 Date: Sun Oct 20 21:22:50 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:130572a linux/fs/xfs/xfs_rtalloc.c - 1.81 - Fix the handling of the realtime device on the mount path - this was broken a few weeks ago with the rework of the target device pointer between the xfs_mount and pb_target structures. From owner-linux-xfs@oss.sgi.com Sun Oct 20 22:10:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 22:10: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 g9L5A9tG026078 for ; Sun, 20 Oct 2002 22:10:09 -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 WAA01633 for ; Sun, 20 Oct 2002 22:10:07 -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 PAA30471 for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 15:08:49 +1000 (EST) Date: Mon, 21 Oct 2002 15:08:49 +1000 (EST) From: Nathan Scott Message-Id: <200210210508.PAA30471@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor header fixup X-archive-position: 1130 X-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 Minor header reorg to get xfs_lrw.h back into line with other xfs/linux headers. Allows us to not repeat the xfs_bdstrat_cb function declaration in several places. Also rename linvfs_set_inode_ops to xfs_set_inodeops since its an auxillary routine not a linvfs method. Date: Sun Oct 20 22:01:58 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:130573a linux/fs/xfs/xfs_buf.h - 1.94 - Don't use local forward declarations of xfs_bdstrat_cb, get these from the appropriate header file now. linux/fs/xfs/xfs_vfsops.c - 1.391 linux/fs/xfs/linux/xfs_super.h - 1.30 linux/fs/xfs/linux/xfs_super.c - 1.219 - Rename linvfs_set_inode_ops to xfs_set_inodeops since its an auxillary routine not a linvfs method. linux/fs/xfs/linux/xfs_lrw.h - 1.30 - Fix up forward struct declarations so that this header can be included in the right spot and so we don't need xfs_bdstrat_cb forward declarations in other places. linux/fs/xfs/linux/xfs_linux.h - 1.86 - Add include of xfs_lrw.h, removed from xfs.h - this is a more consistent spot. linux/fs/xfs/xfs.h - 1.32 - Remove include of xfs_lrw.h, added it to xfs_linux.h. From owner-linux-xfs@oss.sgi.com Sun Oct 20 22:29:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 22:29:42 -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 g9L5TetG027655 for ; Sun, 20 Oct 2002 22:29:40 -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 WAA05240 for ; Sun, 20 Oct 2002 22:29:38 -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 PAA31762 for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 15:28:21 +1000 (EST) Date: Mon, 21 Oct 2002 15:28:21 +1000 (EST) From: Nathan Scott Message-Id: <200210210528.PAA31762@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - EA block split fix X-archive-position: 1131 X-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 [This was backed out a couple of weeks ago on a suspect dbench hang - that turned out to be unrelated, and was fixed in one of Steve's recent checkins. For my reference, this is IRIX bug #857478.] Fix xfs_da_node_split handling of dir/attr buffers for filesystems built with a directory block size larger than the filesystem (and hence attr) blocksize. This does not affect filesystems built with default mkfs.xfs parameters, and only hits when a large number of attributes are set on an inode. Date: Sun Oct 20 22:23:40 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:130577a linux/fs/xfs/xfsidbg.c - 1.208 linux/fs/xfs/xfs_macros.c - 1.46 linux/fs/xfs/xfs_da_btree.c - 1.135 linux/fs/xfs/xfs_da_btree.h - 1.50 linux/fs/xfs/xfs_dir.c - 1.144 linux/fs/xfs/xfs_mount.h - 1.161 linux/fs/xfs/xfs_dir2_node.c - 1.28 linux/fs/xfs/xfs_attr.c - 1.98 linux/fs/xfs/xfs_dir2.c - 1.40 - Fix a problem in the dabuf (dir/attr buffer) layer which deals with calculating when a block should be split in two. Previously there was only one constant used in the test. When V2 directories have a block size larger than the fs block size, the constant is too large for extended attributes. So, replace this constant with two, and make the dabuf code use the correct one based upon being used for attributes or directories. From owner-linux-xfs@oss.sgi.com Sun Oct 20 23:32:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Oct 2002 23:32:46 -0700 (PDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L6WdtG032317 for ; Sun, 20 Oct 2002 23:32:40 -0700 Received: from g8sbr.gppng01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 08:32:29 +0200 Received: by G8SBR.gppng01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 08:32:29 +0200 Message-Id: <43E285EFC5BED511965A0800060DC620013326D9@U8SN4.gppng01.telekom.de> From: "Geiger, Michael" To: linux-xfs@oss.sgi.com Subject: could not pre-alloc tmp space Date: Mon, 21 Oct 2002 08:32:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Geiger@telekom.de Precedence: bulk X-list: linux-xfs Hi, since two weeks I've got a problem running xfs_fsr on my test system - it worked fine before, but now it produces this error message: # xfs_fsr /dev/hda7 could not pre-alloc tmp space: /.fsr/ag0/tmp4323 could not pre-alloc tmp space: /.fsr/ag5/tmp4323 could not pre-alloc tmp space: /.fsr/ag6/tmp4323 I tried upgrading to kernel 2.4.19 with xfs-1.2PRE1 and the latest xfs tools (xfs_fsr version 2.2.1), but it's still the same ... And yes, there is enough free space on this drive! Michael From owner-linux-xfs@oss.sgi.com Mon Oct 21 04:28:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 04:28:23 -0700 (PDT) Received: from manann.kel.de.core.tng.de (manann.kel.de.core.tng.de [213.178.66.15]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LBSKtG007391 for ; Mon, 21 Oct 2002 04:28:20 -0700 Received: from TECHNIK_TEST_WS (162.xsnet.de [213.178.77.162]) by manann.kel.de.core.tng.de (Postfix) with SMTP id EE1F818965 for ; Mon, 21 Oct 2002 13:25:32 +0200 (CEST) From: "Webpartner Travel24.com" To: linux-xfs@oss.sgi.com Subject: Ihre Website bringt jetzt Bares! Message-Id: <20021021112532.EE1F818965@manann.kel.de.core.tng.de> Date: Mon, 21 Oct 2002 13:25:32 +0200 (CEST) X-archive-position: 1133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: webpartner@travel24.com Precedence: bulk X-list: linux-xfs Schlaue Website-Betreiber aufgepasst: Geld verdienen leicht gemacht.. auf Ihrer Homepage.. Ohne Aufwand .. Ohne Kosten fuer Sie! Urlaubstraeume auf Ihrer Website bringen Geld auf Ihr Konto! Wie das funktioniert? Mit dem neuen Partnerprogramm der Travel24.com AG. Bieten Sie Ihren Usern attraktiven Mehrwert zum Thema Reisen - und verdienen Sie an den Online-Buchungen Ihrer User. Und so leicht geht das: Wir senden Ihnen einen Link zu Travel24.com, den Sie prominent auf Ihrer Homepage platzieren und schon winken die dicken Provisionen. Auf was warten Sie noch? Einfach hier klicken und los geht's mit dem Geldverdienen: http://www.travel24.com/buffer.jsp?t=0&l=117 Werden Sie Partner einer starken Urlaubsmarke - wir freuen uns auf Sie! Ihr Travel24.com AG-Team P.S. Jede Umsatz- bzw. Ertragssteigerung ist auch wertsteigernd! From owner-linux-xfs@oss.sgi.com Mon Oct 21 04:37:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 04:37: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 g9LBbmtG008602 for ; Mon, 21 Oct 2002 04:37:48 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 557ED1E2CA8; Mon, 21 Oct 2002 04:37:48 -0700 (PDT) Date: Mon, 21 Oct 2002 04:37:48 -0700 From: Chris Wedgwood To: "Geiger, Michael" Cc: linux-xfs@oss.sgi.com Subject: Re: could not pre-alloc tmp space Message-ID: <20021021113748.GB16449@tapu.f00f.org> References: <43E285EFC5BED511965A0800060DC620013326D9@U8SN4.gppng01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E285EFC5BED511965A0800060DC620013326D9@U8SN4.gppng01.telekom.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1134 X-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 21, 2002 at 08:32:28AM +0200, Geiger, Michael wrote: > # xfs_fsr /dev/hda7 > could not pre-alloc tmp space: /.fsr/ag0/tmp4323 > could not pre-alloc tmp space: /.fsr/ag5/tmp4323 > could not pre-alloc tmp space: /.fsr/ag6/tmp4323 > I tried upgrading to kernel 2.4.19 with xfs-1.2PRE1 and the latest > xfs tools (xfs_fsr version 2.2.1), but it's still the same ... Never kernels (since August 16?) have a fix which means you'll need to upgrade xfs_fsr to a newer version. --cw From owner-linux-xfs@oss.sgi.com Mon Oct 21 05:40:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 05:40:58 -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 g9LCeqtG015485 for ; Mon, 21 Oct 2002 05:40:53 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 13429AC4A; Mon, 21 Oct 2002 14:35:53 +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 B7A85190C8; Mon, 21 Oct 2002 14:35:51 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id D676130881D; Mon, 21 Oct 2002 14:40:49 +0200 (CEST) Message-ID: <3DB3F5D1.2E4FACD1@ch.sauter-bc.com> Date: Mon, 21 Oct 2002 14:40:49 +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: Knut J Bjuland Cc: linux-xfs Subject: Re: XFS for new update redhat kernel 2.4.18-17.8 References: <20021018172002.GA7770@morpheus.matrix.com> <3DB11615.E6A50E18@online.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1135 X-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 Knut J Bjuland schrieb: > > I applied the patch from 2.4.18-14XFS and they applied cleanly, but kdb does > not work or rather does not compile.. There are a redhat kernel with xfs at > http://people.redhat.com/arjanv/2.5/. Since the RPMs were still useful without kdb, are there any chances you make them available somewhere? Simon From owner-linux-xfs@oss.sgi.com Mon Oct 21 07:15:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 07:15:35 -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 g9LEFWtG025975 for ; Mon, 21 Oct 2002 07:15:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA48311; Mon, 21 Oct 2002 09:15: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 JAA45204; Mon, 21 Oct 2002 09:15:25 -0500 (CDT) Subject: Re: could not pre-alloc tmp space From: Eric Sandeen To: "Geiger, Michael" Cc: linux-xfs@oss.sgi.com In-Reply-To: <43E285EFC5BED511965A0800060DC620013326D9@U8SN4.gppng01.telekom.de> References: <43E285EFC5BED511965A0800060DC620013326D9@U8SN4.gppng01.telekom.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 21 Oct 2002 09:11:14 -0500 Message-Id: <1035209474.28394.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1136 X-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 As Chris pointed out, you actually need newer tools... xfsdump >= 2.2.2. I'll make sure that's available on the ftp site today. -Eric On Mon, 2002-10-21 at 01:32, Geiger, Michael wrote: > Hi, > > since two weeks I've got a problem running xfs_fsr on my test system - it worked fine before, but now it produces this error message: > > # xfs_fsr /dev/hda7 > could not pre-alloc tmp space: /.fsr/ag0/tmp4323 > could not pre-alloc tmp space: /.fsr/ag5/tmp4323 > could not pre-alloc tmp space: /.fsr/ag6/tmp4323 > > I tried upgrading to kernel 2.4.19 with xfs-1.2PRE1 and the latest xfs tools (xfs_fsr version 2.2.1), but it's still the same ... > > And yes, there is enough free space on this drive! > > > Michael > -- 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 21 07:50:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 07:50:33 -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 g9LEoUtG028816 for ; Mon, 21 Oct 2002 07:50:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA13078 for ; Mon, 21 Oct 2002 09:50:24 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA39243 for ; Mon, 21 Oct 2002 09:50:21 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g9LM5Qi15388 for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 18:05:26 -0400 Resent-Message-Id: <200210212205.g9LM5Qi15388@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA36470 for ; Mon, 21 Oct 2002 09:41:42 -0500 (CDT) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g9LEfepx27117987 for ; Mon, 21 Oct 2002 07:41:41 -0700 (PDT) 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 g9LEedUV007905 for ; Mon, 21 Oct 2002 16:40:39 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9LEed7q007904 for hch@sgi.com; Mon, 21 Oct 2002 16:40:39 +0200 Date: Mon, 21 Oct 2002 16:40:39 +0200 Message-Id: <200210211440.g9LEed7q007904@lab343.munich.sgi.com> Subject: TAKE - remove nopkg() alias for ENOSYS To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 21 Oct 2002 18:05:26 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1137 X-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@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Oct 21 07:40:44 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:130598a linux/fs/xfs/xfs_dmapi.h - 1.32 linux/fs/xfs/xfs_log_recover.c - 1.247 - use ENOSYS instead of nopkg() linux/fs/xfs/linux/xfs_linux.h - 1.88 - remove nopkg() and LONGLONG_MAX declarations From owner-linux-xfs@oss.sgi.com Mon Oct 21 11:56:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 11:56:42 -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 g9LIuduV002795 for ; Mon, 21 Oct 2002 11:56:39 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) 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 KAA04489 for ; Mon, 21 Oct 2002 10:12:45 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA24575 for ; Mon, 21 Oct 2002 12:07:44 -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 MAA17696 for ; Mon, 21 Oct 2002 12:07:44 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9LH3Wg30383; Mon, 21 Oct 2002 12:03:32 -0500 Message-Id: <200210211703.g9LH3Wg30383@stout.americas.sgi.com> Date: Mon, 21 Oct 2002 12:03:32 -0500 Subject: TAKE - fix race in _pagebuf_free_bh() X-archive-position: 1139 X-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 Also remove setting bh->b_state = 0 after getting a prealloc'd bh, we zero the whole struct after we get it anyway. fix race in _pagebuf_free_bh() CONTRIBUTED: Mike Ovsiannikov Date: Mon Oct 21 10:06: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:130613a linux/fs/xfs/pagebuf/page_buf.c - 1.67 From owner-linux-xfs@oss.sgi.com Mon Oct 21 11:56:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 11:56:42 -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 g9LIuduT002795 for ; Mon, 21 Oct 2002 11:56:39 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) 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 KAA03493 for ; Mon, 21 Oct 2002 10:43:29 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA35236; Mon, 21 Oct 2002 12:38:27 -0500 (CDT) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA23078; Mon, 21 Oct 2002 12:38:27 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9LHcWb9014926; Mon, 21 Oct 2002 12:38:32 -0500 Subject: Re: v1.2 installer crash From: Russell Cattelan To: Florin Andrei Cc: linux-xfs In-Reply-To: <1035016560.1787.1.camel@stantz.corp.sgi.com> References: <1035016560.1787.1.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Oct 2002 12:38:32 -0500 Message-Id: <1035221912.25622.58.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1138 X-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 It is very strange that the installer is doing lvm stuff then. Did you have any lvm partitions at one point? The installer might be discovering something it shouldn't and trying to deal with it. You might want to wipe all partition information before starting the install. It's also possible anaconda is incorrectly identifying xfs partitions as lvm partitions, but that's a bug in anaconda. On Sat, 2002-10-19 at 03:36, Florin Andrei wrote: > Just a plain SGI1200, with 4xSCSI. I'm not sure what vgchange means. > > BTW, the plain RH8.0 installer worked without any problems. > > On Fri, 2002-10-18 at 19:19, Eric Sandeen wrote: > > Did you have LVM on this machine? > > > > Looks like it failed because "vgchange" failed... > > > > -Eric > > > > On 18 Oct 2002, Florin Andrei wrote: > > > > > The RH8.0 installer (1.2pre) crashed. I didn't do any of the "forbidden" > > > things mentioned in the README (text install, upgrade, use grub) yet it > > > crashed. > > > I attached the crash dump. > > > > > > The system is a SGI1200. > > > I cannot repeat the experiment, because the machine is not available > > > anymore. > > > > > > -- > > > Florin Andrei > > > > > > Writing a book on wireless security > > > is like writing a book on safe skydiving. > > > > > > > > -- > Florin Andrei > > Writing a book on wireless security > is like writing a book on safe skydiving. > From owner-linux-xfs@oss.sgi.com Mon Oct 21 11:56:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 11:56:42 -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 g9LIuduR002795 for ; Mon, 21 Oct 2002 11:56:39 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) 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 LAA07460 for ; Mon, 21 Oct 2002 11:29:26 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA97703 for ; Mon, 21 Oct 2002 13:24: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 NAA99516 for ; Mon, 21 Oct 2002 13:24:25 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9LIKtm25752; Mon, 21 Oct 2002 13:20:55 -0500 Message-Id: <200210211820.g9LIKtm25752@jen.americas.sgi.com> Date: Mon, 21 Oct 2002 13:20:55 -0500 Subject: TAKE - merge up to 2.5.44 To: linux-xfs@oss.sgi.com X-archive-position: 1138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Oct 21 11:20:35 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:130624a linux/arch/ppc/boot/simple/misc.c - 1.1 linux/include/asm-i386/edd.h - 1.1 linux/Documentation/filesystems/sysfs.txt - 1.1 linux/arch/x86_64/mm/pageattr.c - 1.1 linux/drivers/pnp/pnpbios/core.c - 1.1 linux/scripts/Makefile.clean - 1.1 linux/Documentation/pnp.txt - 1.1 linux/Documentation/tipar.txt - 1.1 linux/arch/ppc/boot/simple/relocate.S - 1.1 linux/arch/ppc/boot/lib/div64.S - 1.1 linux/arch/i386/mm/highmem.c - 1.1 linux/drivers/pnp/resource.c - 1.1 linux/arch/x86_64/kernel/profile.c - 1.1 linux/drivers/pnp/names.c - 1.1 linux/arch/ppc/lib/div64.S - 1.1 linux/drivers/isdn/i4l/isdn_ppp_ccp.h - 1.1 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.1 linux/net/bluetooth/bnep/Makefile.lib - 1.1 linux/fs/sysfs/Makefile - 1.1 linux/drivers/pnp/base.h - 1.1 linux/drivers/pnp/compat.c - 1.1 linux/drivers/pnp/core.c - 1.1 linux/drivers/pnp/driver.c - 1.1 linux/include/asm-x86_64/ioctl32.h - 1.1 linux/drivers/pnp/pnpbios/Makefile - 1.1 linux/arch/sparc/kernel/asm-offsets.c - 1.1 linux/include/asm-x86_64/nmi.h - 1.1 linux/fs/sysfs/inode.c - 1.1 linux/arch/ppc/platforms/pal4.h - 1.1 linux/arch/i386/kernel/edd.c - 1.1 linux/drivers/pnp/isapnp/proc.c - 1.1 linux/drivers/pnp/system.c - 1.1 linux/include/linux/sysfs.h - 1.1 linux/include/linux/ioctl32.h - 1.1 linux/arch/ppc/platforms/pal4_pci.c - 1.1 linux/arch/ppc/platforms/pal4_serial.h - 1.1 linux/arch/ppc/platforms/pal4_setup.c - 1.1 linux/drivers/pnp/isapnp/core.c - 1.1 linux/drivers/pnp/isapnp/Makefile - 1.1 linux/drivers/pnp/interface.c - 1.1 linux/include/linux/pnp.h - 1.1 linux/drivers/pnp/idlist.h - 1.1 linux/drivers/pnp/pnpbios/proc.c - 1.1 linux/scripts/lxdialog/Makefile - 1.8 linux/scripts/Makefile - 1.11 linux/net/sunrpc/svc.c - 1.16 linux/net/sunrpc/sunrpc_syms.c - 1.15 linux/net/socket.c - 1.45 linux/net/netsyms.c - 1.53 linux/net/ipv6/tcp_ipv6.c - 1.42 linux/net/ipv6/mcast.c - 1.21 linux/net/ipv4/udp.c - 1.34 linux/net/ipv4/tcp_ipv4.c - 1.52 linux/net/ipv4/tcp.c - 1.46 linux/net/ipv4/raw.c - 1.26 linux/net/ipv4/ip_sockglue.c - 1.20 linux/net/ipv4/ip_output.c - 1.37 linux/net/ipv4/ip_forward.c - 1.8 linux/net/ipv4/icmp.c - 1.34 linux/net/ipv4/af_inet.c - 1.43 linux/net/core/sock.c - 1.30 linux/net/core/dst.c - 1.11 linux/mm/vmscan.c - 1.118 linux/mm/vmalloc.c - 1.46 linux/mm/filemap.c - 1.140 linux/lib/Makefile - 1.14 linux/kernel/signal.c - 1.45 linux/kernel/ksyms.c - 1.172 linux/include/scsi/sg.h - 1.18 linux/include/net/udp.h - 1.10 linux/include/net/tcp.h - 1.38 linux/include/net/sock.h - 1.37 linux/include/net/ipv6.h - 1.11 linux/include/net/ip.h - 1.20 linux/include/net/dst.h - 1.8 linux/include/net/addrconf.h - 1.10 linux/include/linux/udp.h - 1.3 linux/include/linux/tcp.h - 1.13 linux/include/linux/sunrpc/svc.h - 1.10 linux/include/linux/skbuff.h - 1.28 linux/include/linux/sched.h - 1.89 linux/include/linux/nfsd/nfsd.h - 1.17 linux/include/linux/net.h - 1.12 linux/include/linux/nbd.h - 1.19 linux/include/linux/mm.h - 1.105 linux/include/linux/list.h - 1.22 linux/include/linux/kernel.h - 1.39 linux/include/linux/isdn_ppp.h - 1.13 linux/include/linux/isdn.h - 1.29 linux/include/linux/ip.h - 1.6 linux/include/linux/init.h - 1.21 linux/include/linux/genhd.h - 1.29 linux/include/linux/fs.h - 1.196 linux/include/linux/cdrom.h - 1.25 linux/include/linux/blkdev.h - 1.75 linux/include/asm-sparc64/unistd.h - 1.27 linux/include/asm-sparc64/siginfo.h - 1.12 linux/include/asm-sparc/unistd.h - 1.25 linux/include/asm-sparc/system.h - 1.15 linux/include/asm-sparc/siginfo.h - 1.13 linux/include/asm-sparc/ptrace.h - 1.3 linux/include/asm-sparc/checksum.h - 1.7 linux/include/asm-ppc/system.h - 1.26 linux/include/asm-ppc/pci-bridge.h - 1.12 linux/include/asm-ppc/checksum.h - 1.6 linux/include/asm-mips/system.h - 1.12 linux/include/asm-mips/checksum.h - 1.7 linux/include/asm-m68k/checksum.h - 1.4 linux/include/asm-i386/system.h - 1.28 linux/include/asm-i386/smp.h - 1.24 linux/include/asm-i386/checksum.h - 1.8 linux/include/asm-arm/system.h - 1.24 linux/include/asm-arm/checksum.h - 1.11 linux/include/asm-alpha/system.h - 1.24 linux/include/asm-alpha/checksum.h - 1.4 linux/fs/read_write.c - 1.27 linux/fs/nfsd/vfs.c - 1.58 linux/fs/nfsd/stats.c - 1.11 linux/fs/nfsd/nfssvc.c - 1.27 linux/fs/nfsd/nfsproc.c - 1.28 linux/fs/nfsd/nfsctl.c - 1.36 linux/fs/nfsd/nfs3proc.c - 1.18 linux/fs/nfsd/export.c - 1.43 linux/fs/nfs/proc.c - 1.19 linux/fs/nfs/inode.c - 1.57 linux/fs/locks.c - 1.34 linux/fs/lockd/svc.c - 1.23 linux/fs/buffer.c - 1.140 linux/fs/block_dev.c - 1.66 linux/fs/Makefile - 1.72 linux/drivers/zorro/Makefile - 1.12 linux/drivers/video/Makefile - 1.46 linux/drivers/scsi/wd33c93.c - 1.9 linux/drivers/scsi/sym53c8xx.c - 1.36 linux/drivers/scsi/st.c - 1.55 linux/drivers/scsi/sr_vendor.c - 1.15 linux/drivers/scsi/sr_ioctl.c - 1.29 linux/drivers/scsi/sr.c - 1.56 linux/drivers/scsi/sg.c - 1.41 linux/drivers/scsi/sd.h - 1.11 linux/drivers/scsi/sd.c - 1.76 linux/drivers/scsi/scsi_syms.c - 1.22 linux/drivers/scsi/scsi_proc.c - 1.12 linux/drivers/scsi/scsi_ioctl.c - 1.26 linux/drivers/scsi/scsi_error.c - 1.33 linux/drivers/scsi/scsi_debug.c - 1.24 linux/drivers/scsi/scsi.h - 1.37 linux/drivers/scsi/scsi.c - 1.63 linux/drivers/scsi/hosts.h - 1.28 linux/drivers/scsi/hosts.c - 1.34 linux/drivers/scsi/fcal.c - 1.11 linux/drivers/scsi/esp.c - 1.26 linux/drivers/scsi/NCR53C9x.c - 1.18 linux/drivers/scsi/Makefile - 1.42 linux/drivers/pnp/Makefile - 1.15 linux/drivers/pnp/Config.in - 1.9 linux/drivers/pci/Makefile - 1.26 linux/drivers/nubus/nubus.c - 1.10 linux/drivers/net/hamradio/soundmodem/Makefile - 1.8 linux/drivers/net/eepro100.c - 1.51 linux/drivers/net/3c59x.c - 1.39 linux/drivers/isdn/isdnloop/isdnloop.c - 1.15 linux/drivers/char/sysrq.c - 1.30 linux/drivers/char/specialix.c - 1.15 linux/drivers/char/isicom.c - 1.21 linux/drivers/char/ftape/zftape/zftape-vtbl.h - 1.3 linux/drivers/char/ftape/lowlevel/ftape-rw.h - 1.4 linux/drivers/char/Makefile - 1.76 linux/drivers/cdrom/sonycd535.c - 1.32 linux/drivers/cdrom/sjcd.c - 1.25 linux/drivers/cdrom/sbpcd.c - 1.32 linux/drivers/cdrom/optcd.c - 1.26 linux/drivers/cdrom/mcdx.c - 1.23 linux/drivers/cdrom/mcd.c - 1.26 linux/drivers/cdrom/gscd.c - 1.26 linux/drivers/cdrom/cm206.c - 1.27 linux/drivers/cdrom/cdu31a.c - 1.26 linux/drivers/cdrom/cdrom.c - 1.50 linux/drivers/cdrom/aztcd.c - 1.28 linux/drivers/block/z2ram.c - 1.22 linux/drivers/block/xd.c - 1.49 linux/drivers/block/swim3.c - 1.24 linux/drivers/block/rd.c - 1.65 linux/drivers/block/paride/pf.c - 1.33 linux/drivers/block/paride/pd.c - 1.41 linux/drivers/block/paride/pcd.c - 1.29 linux/drivers/block/paride/epat.c - 1.8 linux/drivers/block/nbd.c - 1.47 linux/drivers/block/loop.c - 1.72 linux/drivers/block/ll_rw_blk.c - 1.120 linux/drivers/block/genhd.c - 1.39 linux/drivers/block/floppy.c - 1.56 linux/drivers/block/ataflop.c - 1.31 linux/drivers/block/amiflop.c - 1.32 linux/drivers/block/acsi.c - 1.41 linux/drivers/block/Config.in - 1.41 linux/drivers/acorn/scsi/powertec.c - 1.16 linux/drivers/acorn/scsi/eesox.c - 1.16 linux/drivers/acorn/scsi/cumana_2.c - 1.16 linux/drivers/acorn/scsi/acornscsi.c - 1.20 linux/drivers/acorn/block/mfmhd.c - 1.34 linux/drivers/acorn/block/fd1772.c - 1.25 linux/arch/sparc64/solaris/socket.c - 1.10 linux/arch/sparc64/lib/blockops.S - 1.20 linux/arch/sparc64/lib/VIScopy.S - 1.9 linux/arch/sparc64/kernel/time.c - 1.25 linux/arch/sparc64/kernel/systbls.S - 1.34 linux/arch/sparc64/kernel/sys_sparc32.c - 1.62 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.50 linux/arch/sparc64/kernel/signal.c - 1.27 linux/arch/sparc64/kernel/ioctl32.c - 1.59 linux/arch/sparc64/defconfig - 1.82 linux/arch/sparc/kernel/wuf.S - 1.6 linux/arch/sparc/kernel/wof.S - 1.6 linux/arch/sparc/kernel/time.c - 1.22 linux/arch/sparc/kernel/systbls.S - 1.27 linux/arch/sparc/kernel/sparc_ksyms.c - 1.32 linux/arch/sparc/kernel/signal.c - 1.30 linux/arch/sparc/kernel/sclow.S - 1.4 linux/arch/sparc/kernel/rtrap.S - 1.13 linux/arch/sparc/kernel/etrap.S - 1.6 linux/arch/sparc/kernel/entry.S - 1.15 linux/arch/sparc/kernel/check_asm.sh - 1.8 linux/arch/sparc/kernel/Makefile - 1.19 linux/arch/sparc/defconfig - 1.37 linux/arch/sparc/boot/Makefile - 1.9 linux/arch/sparc/Makefile - 1.19 linux/arch/ppc/lib/Makefile - 1.12 linux/arch/ppc/kernel/ppc_ksyms.c - 1.51 linux/arch/ppc/kernel/misc.S - 1.49 linux/arch/ppc/kernel/indirect_pci.c - 1.10 linux/arch/ppc/defconfig - 1.45 linux/arch/ppc/config.in - 1.61 linux/arch/ppc/boot/Makefile - 1.19 linux/arch/ppc/Makefile - 1.32 linux/arch/mips/lib/csum_partial_copy.c - 1.6 linux/arch/mips/kernel/mips_ksyms.c - 1.13 linux/arch/m68k/lib/checksum.c - 1.3 linux/arch/m68k/kernel/m68k_ksyms.c - 1.12 linux/arch/m68k/atari/stram.c - 1.22 linux/arch/i386/mm/init.c - 1.45 linux/arch/i386/mm/Makefile - 1.11 linux/arch/i386/lib/old-checksum.c - 1.3 linux/arch/i386/lib/Makefile - 1.19 linux/arch/i386/kernel/setup.c - 1.84 linux/arch/i386/kernel/irq.c - 1.50 linux/arch/i386/kernel/io_apic.c - 1.47 linux/arch/i386/kernel/i386_ksyms.c - 1.60 linux/arch/i386/kernel/Makefile - 1.39 linux/arch/i386/defconfig - 1.115 linux/arch/i386/config.in - 1.98 linux/arch/i386/boot/setup.S - 1.29 linux/arch/i386/boot/compressed/Makefile - 1.13 linux/arch/i386/boot/Makefile - 1.18 linux/arch/i386/Makefile - 1.37 linux/arch/arm/mm/Makefile - 1.21 linux/arch/arm/lib/Makefile - 1.24 linux/arch/arm/kernel/time.c - 1.19 linux/arch/arm/kernel/ecard.c - 1.23 linux/arch/arm/kernel/Makefile - 1.23 linux/arch/arm/boot/compressed/misc.c - 1.7 linux/arch/arm/boot/compressed/Makefile - 1.25 linux/arch/arm/boot/Makefile - 1.20 linux/arch/arm/Makefile - 1.36 linux/arch/alpha/lib/csum_partial_copy.c - 1.5 linux/arch/alpha/kernel/alpha_ksyms.c - 1.37 linux/arch/alpha/defconfig - 1.32 linux/Rules.make - 1.34 linux/Makefile - 1.226 linux/MAINTAINERS - 1.123 linux/Documentation/i386/zero-page.txt - 1.4 linux/CREDITS - 1.90 linux/net/decnet/dn_dev.c - 1.16 linux/net/decnet/af_decnet.c - 1.35 linux/include/linux/ide.h - 1.68 linux/drivers/acorn/scsi/arxescsi.c - 1.13 linux/arch/i386/vmlinux.lds.S - 1.10 linux/drivers/block/cpqarray.h - 1.11 linux/drivers/block/cpqarray.c - 1.61 linux/include/asm-i386/setup.h - 1.4 linux/drivers/parport/parport_pc.c - 1.48 linux/include/asm-i386/apic.h - 1.20 linux/include/linux/isapnp.h - 1.13 linux/fs/partitions/msdos.c - 1.26 linux/fs/partitions/check.c - 1.57 linux/drivers/pnp/isapnp_proc.c - 1.17 linux/drivers/pnp/isapnp.c - 1.32 linux/drivers/atm/Makefile - 1.21 linux/drivers/block/DAC960.h - 1.20 linux/drivers/block/DAC960.c - 1.60 linux/arch/sh/lib/old-checksum.c - 1.3 linux/arch/sh/lib/Makefile - 1.9 linux/arch/sh/kernel/sh_ksyms.c - 1.12 linux/drivers/scsi/ips.h - 1.17 linux/include/asm-sh/system.h - 1.13 linux/include/asm-sh/checksum.h - 1.9 linux/drivers/block/swim_iop.c - 1.19 linux/arch/arm/boot/compressed/vmlinux.lds.in - 1.6 linux/include/asm-i386/highmem.h - 1.15 linux/include/asm-ppc/div64.h - 1.4 linux/arch/ppc/configs/walnut_defconfig - 1.20 linux/arch/ppc/configs/pmac_defconfig - 1.11 linux/arch/ppc/configs/oak_defconfig - 1.20 linux/arch/ppc/configs/mbx_defconfig - 1.15 linux/arch/ppc/configs/gemini_defconfig - 1.22 linux/arch/ppc/configs/common_defconfig - 1.32 linux/arch/ppc/configs/apus_defconfig - 1.18 linux/drivers/scsi/scsi_merge.c - 1.42 linux/drivers/scsi/scsi_lib.c - 1.52 linux/drivers/sbus/char/jsflash.c - 1.26 linux/drivers/pnp/quirks.c - 1.10 linux/include/asm-i386/io_apic.h - 1.8 linux/drivers/scsi/scsi_scan.c - 1.33 linux/arch/ia64/ia32/sys_ia32.c - 1.33 linux/arch/ia64/defconfig - 1.22 linux/arch/ia64/lib/csum_partial_copy.c - 1.4 linux/include/asm-ia64/checksum.h - 1.3 linux/include/asm-ia64/system.h - 1.20 linux/arch/i386/kernel/microcode.c - 1.20 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.7 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.7 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.8 linux/include/asm-mips64/checksum.h - 1.4 linux/include/asm-mips64/system.h - 1.7 linux/arch/mips64/lib/csum_partial_copy.c - 1.4 linux/arch/mips64/kernel/linux32.c - 1.13 linux/arch/mips64/kernel/mips64_ksyms.c - 1.9 linux/net/econet/af_econet.c - 1.16 linux/drivers/ide/ide.c - 1.74 linux/drivers/ide/ide-probe.c - 1.44 linux/drivers/ide/ide-geometry.c - 1.18 linux/drivers/ide/ide-cd.c - 1.52 linux/Documentation/DocBook/Makefile - 1.38 linux/drivers/char/rio/rio_linux.c - 1.16 linux/arch/arm/def-configs/lart - 1.9 linux/include/asm-s390/system.h - 1.10 linux/include/asm-s390/checksum.h - 1.6 linux/arch/arm/def-configs/assabet - 1.11 linux/arch/arm/def-configs/graphicsclient - 1.10 linux/kdb/modules/kdbm_vm.c - 1.27 linux/kdb/Makefile - 1.16 linux/drivers/usb/storage/transport.c - 1.32 linux/drivers/mtd/ftl.c - 1.28 linux/arch/ppc/configs/rpxlite_defconfig - 1.15 linux/arch/ppc/configs/rpxcllf_defconfig - 1.16 linux/arch/ppc/configs/est8260_defconfig - 1.17 linux/arch/ppc/configs/bseip_defconfig - 1.15 linux/net/ipv4/tcp_minisocks.c - 1.19 linux/drivers/net/natsemi.c - 1.25 linux/drivers/media/video/cpia.h - 1.6 linux/arch/arm/boot/bootp/Makefile - 1.6 linux/arch/arm/def-configs/shark - 1.10 linux/arch/i386/kernel/bluesmoke.c - 1.29 linux/drivers/block/cciss.c - 1.48 linux/drivers/block/cciss.h - 1.17 linux/drivers/md/linear.c - 1.15 linux/drivers/md/md.c - 1.62 linux/drivers/scsi/cpqfcTSinit.c - 1.21 linux/arch/sparc64/lib/U3memcpy.S - 1.2 linux/arch/sparc64/lib/U3copy_to_user.S - 1.2 linux/arch/sparc64/lib/U3copy_from_user.S - 1.3 linux/arch/arm/def-configs/neponset - 1.10 linux/arch/arm/def-configs/pangolin - 1.8 linux/arch/parisc/lib/checksum.c - 1.2 linux/include/asm-parisc/checksum.h - 1.2 linux/include/asm-parisc/system.h - 1.3 linux/drivers/scsi/osst.c - 1.17 linux/fs/reiserfs/ioctl.c - 1.9 linux/arch/ppc/configs/power3_defconfig - 1.13 linux/arch/ppc/configs/ibmchrp_defconfig - 1.13 linux/include/asm-s390x/checksum.h - 1.4 linux/arch/s390x/kernel/linux32.c - 1.18 linux/arch/cris/lib/old_checksum.c - 1.3 linux/include/asm-s390x/system.h - 1.8 linux/include/asm-cris/system.h - 1.6 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.5 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.7 linux/drivers/scsi/aic7xxx/Makefile - 1.8 linux/arch/arm/tools/Makefile - 1.7 linux/arch/ppc/configs/TQM860L_defconfig - 1.15 linux/arch/ppc/configs/TQM850L_defconfig - 1.13 linux/arch/ppc/configs/TQM823L_defconfig - 1.13 linux/arch/ppc/configs/SPD823TS_defconfig - 1.13 linux/arch/ppc/configs/SM850_defconfig - 1.13 linux/arch/ppc/configs/IVMS8_defconfig - 1.15 linux/arch/ppc/boot/prep/misc.c - 1.10 linux/arch/ppc/boot/prep/Makefile - 1.12 linux/arch/ppc/boot/lib/Makefile - 1.3 linux/arch/ppc/boot/images/Makefile - 1.3 linux/arch/ppc/boot/common/misc-simple.c - 1.6 linux/arch/ppc/boot/common/Makefile - 1.4 linux/include/net/bluetooth/hci.h - 1.7 linux/include/net/bluetooth/hci_core.h - 1.7 linux/include/net/bluetooth/l2cap.h - 1.5 linux/drivers/bluetooth/hci_usb.c - 1.15 linux/drivers/bluetooth/Makefile - 1.8 linux/net/bluetooth/Config.in - 1.4 linux/net/bluetooth/Makefile - 1.7 linux/net/bluetooth/hci_core.c - 1.10 linux/net/bluetooth/hci_sock.c - 1.9 linux/net/bluetooth/syms.c - 1.5 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.10 linux/drivers/message/fusion/linux_compat.h - 1.6 linux/arch/arm/def-configs/anakin - 1.5 linux/arch/arm/def-configs/flexanet - 1.7 linux/arch/arm/def-configs/h3600 - 1.6 linux/arch/arm/def-configs/jornada720 - 1.7 linux/arch/arm/def-configs/pleb - 1.5 linux/arch/arm/mach-sa1100/sa1111-pcibuf.c - 1.5 linux/arch/arm/mach-sa1100/pcipool.c - 1.3 linux/include/asm-ppc/sections.h - 1.3 linux/drivers/scsi/53c700.c - 1.11 linux/drivers/scsi/53c700.h - 1.6 linux/drivers/message/i2o/i2o_block.c - 1.26 linux/arch/arm/def-configs/adsbitsy - 1.6 linux/arch/arm/def-configs/cerfcube - 1.6 linux/arch/arm/def-configs/cerfpda - 1.6 linux/arch/arm/def-configs/cerfpod - 1.6 linux/arch/arm/def-configs/epxa10db - 1.6 linux/arch/arm/def-configs/graphicsmaster - 1.6 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.9 linux/fs/driverfs/inode.c - 1.24 linux/fs/bio.c - 1.22 linux/include/linux/driverfs_fs.h - 1.6 linux/include/linux/device.h - 1.21 linux/arch/arm/def-configs/adi_evb - 1.5 linux/arch/arm/def-configs/iq80310 - 1.10 linux/arch/arm/def-configs/shannon - 1.5 linux/arch/arm/def-configs/system3 - 1.5 linux/drivers/block/cciss_scsi.c - 1.5 linux/arch/i386/Config.help - 1.19 linux/drivers/char/Config.help - 1.14 linux/drivers/pnp/Config.help - 1.3 linux/drivers/net/mii.c - 1.7 linux/drivers/base/interface.c - 1.9 linux/drivers/base/core.c - 1.18 linux/drivers/pci/pci-driver.c - 1.12 linux/drivers/pnp/pnpbios_core.c - 1.13 linux/drivers/pnp/pnpbios_proc.c - 1.6 linux/include/linux/pnpbios.h - 1.4 linux/sound/pci/ens1370.c - 1.11 linux/arch/ppc/boot/common/relocate.S - 1.3 linux/arch/ppc/boot/simple/Makefile - 1.7 linux/arch/ppc/configs/FADS_defconfig - 1.4 linux/sound/oss/sound_config.h - 1.2 linux/arch/ppc/configs/adir_defconfig - 1.4 linux/arch/ppc/configs/ash_defconfig - 1.4 linux/arch/ppc/configs/cpci405_defconfig - 1.6 linux/arch/ppc/configs/ep405_defconfig - 1.4 linux/arch/ppc/configs/ev64260_defconfig - 1.4 linux/arch/ppc/configs/iSeries_defconfig - 1.4 linux/arch/ppc/configs/k2_defconfig - 1.8 linux/arch/ppc/configs/lopec_defconfig - 1.5 linux/arch/ppc/configs/mcpn765_defconfig - 1.4 linux/arch/ppc/configs/menf1_defconfig - 1.8 linux/arch/ppc/configs/pplus_defconfig - 1.8 linux/arch/ppc/configs/prpmc750_defconfig - 1.4 linux/arch/ppc/configs/prpmc800_defconfig - 1.4 linux/arch/ppc/configs/redwood5_defconfig - 1.5 linux/arch/ppc/configs/redwood_defconfig - 1.4 linux/arch/ppc/configs/sandpoint_defconfig - 1.9 linux/arch/ppc/configs/spruce_defconfig - 1.4 linux/arch/ppc/configs/zx4500_defconfig - 1.4 linux/sound/oss/opl3sa2.c - 1.4 linux/sound/oss/ite8172.c - 1.4 linux/arch/ppc/platforms/Makefile - 1.7 linux/arch/ppc/platforms/pcore_setup.c - 1.4 linux/arch/x86_64/Config.help - 1.3 linux/arch/x86_64/Makefile - 1.9 linux/arch/x86_64/boot/compressed/misc.c - 1.3 linux/arch/x86_64/config.in - 1.13 linux/arch/x86_64/defconfig - 1.12 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.6 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.10 linux/arch/x86_64/ia32/ia32_signal.c - 1.6 linux/arch/x86_64/ia32/ia32entry.S - 1.5 linux/arch/x86_64/ia32/sys_ia32.c - 1.9 linux/arch/x86_64/kernel/Makefile - 1.8 linux/arch/x86_64/kernel/apic.c - 1.5 linux/arch/x86_64/kernel/mpparse.c - 1.5 linux/arch/x86_64/kernel/mtrr.c - 1.8 linux/arch/x86_64/kernel/nmi.c - 1.4 linux/arch/x86_64/kernel/process.c - 1.9 linux/arch/x86_64/kernel/setup.c - 1.5 linux/arch/x86_64/kernel/traps.c - 1.8 linux/arch/x86_64/mm/Makefile - 1.3 linux/arch/x86_64/mm/fault.c - 1.6 linux/arch/x86_64/mm/init.c - 1.8 linux/arch/x86_64/mm/ioremap.c - 1.6 linux/sound/oss/ad1848.c - 1.4 linux/sound/oss/Makefile - 1.8 linux/include/asm-x86_64/param.h - 1.3 linux/include/asm-x86_64/namei.h - 1.2 linux/include/asm-x86_64/ipcbuf.h - 1.2 linux/include/asm-x86_64/ipc.h - 1.5 linux/include/asm-x86_64/io_apic.h - 1.4 linux/include/asm-x86_64/ide.h - 1.8 linux/include/asm-x86_64/ia32.h - 1.4 linux/include/asm-x86_64/hw_irq.h - 1.3 linux/include/asm-x86_64/system.h - 1.7 linux/include/asm-x86_64/socket32.h - 1.2 linux/include/asm-x86_64/softirq.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.8 linux/include/asm-ppc64/hardirq.h - 1.7 linux/arch/ppc64/mm/fault.c - 1.6 linux/arch/ppc64/mm/init.c - 1.10 linux/include/asm-ppc64/checksum.h - 1.2 linux/include/asm-ppc64/a.out.h - 1.2 linux/include/asm-ppc64/ipc.h - 1.2 linux/arch/ppc64/Makefile - 1.11 linux/arch/ppc64/boot/Makefile - 1.6 linux/arch/ppc64/boot/piggyback.c - 1.2 linux/arch/ppc64/config.in - 1.12 linux/arch/ppc64/defconfig - 1.10 linux/arch/ppc64/kernel/chrp_setup.c - 1.8 linux/arch/ppc64/kernel/eeh.c - 1.5 linux/arch/ppc64/kernel/entry.S - 1.9 linux/arch/ppc64/kernel/ioctl32.c - 1.8 linux/arch/ppc64/kernel/misc.S - 1.9 linux/arch/ppc64/kernel/open_pic.c - 1.6 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.7 linux/arch/ppc64/kernel/pci.c - 1.7 linux/arch/ppc64/kernel/pci.h - 1.3 linux/arch/ppc64/kernel/process.c - 1.9 linux/arch/ppc64/kernel/prom.c - 1.8 linux/arch/ppc64/kernel/ptrace.c - 1.4 linux/arch/ppc64/kernel/ptrace32.c - 1.5 linux/arch/ppc64/kernel/setup.c - 1.8 linux/arch/ppc64/kernel/signal.c - 1.10 linux/arch/ppc64/kernel/signal32.c - 1.9 linux/arch/ppc64/kernel/smp.c - 1.10 linux/arch/ppc64/kernel/sys_ppc32.c - 1.11 linux/arch/ppc64/kernel/syscalls.c - 1.6 linux/arch/ppc64/kernel/traps.c - 1.8 linux/arch/ppc64/kernel/udbg.c - 1.4 linux/arch/ppc64/kernel/xics.c - 1.7 linux/arch/ppc64/mm/extable.c - 1.3 linux/include/asm-ppc64/ucontext.h - 1.2 linux/arch/ppc64/xmon/xmon.c - 1.8 linux/include/asm-ppc64/machdep.h - 1.8 linux/include/asm-ppc64/hw_irq.h - 1.5 linux/include/asm-ppc64/udbg.h - 1.2 linux/include/asm-ppc64/thread_info.h - 1.5 linux/include/asm-ppc64/system.h - 1.7 linux/include/asm-ppc64/stat.h - 1.2 linux/include/asm-ppc64/siginfo.h - 1.5 linux/include/asm-ppc64/sigcontext.h - 1.2 linux/include/asm-ppc64/semaphore.h - 1.4 linux/include/asm-ppc64/ppc32.h - 1.2 linux/include/asm-ppc64/processor.h - 1.9 linux/include/asm-ppc64/posix_types.h - 1.3 linux/include/asm-ppc64/pgtable.h - 1.8 linux/include/asm-ppc64/pci-bridge.h - 1.3 linux/drivers/net/e1000/e1000_main.c - 1.13 linux/Documentation/networking/e1000.txt - 1.5 linux/drivers/net/e1000/e1000_osdep.h - 1.6 linux/drivers/net/e1000/e1000.h - 1.8 linux/drivers/net/e1000/e1000_ethtool.c - 1.6 linux/drivers/net/e1000/e1000_param.c - 1.5 linux/drivers/net/e1000/e1000_proc.c - 1.4 linux/arch/arm/def-configs/badge4 - 1.7 linux/arch/arm/def-configs/fortunet - 1.4 linux/arch/arm/def-configs/stork - 1.5 linux/drivers/pcmcia/sa1111_generic.c - 1.4 linux/drivers/net/e100/e100_proc.c - 1.7 linux/drivers/net/e100/e100.h - 1.9 linux/drivers/net/e100/e100_main.c - 1.9 linux/mm/msync.c - 1.8 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.7 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.7 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-modules - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-syn1-0 - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-sp - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp-modules - 1.6 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-sp - 1.6 linux/fs/libfs.c - 1.8 linux/drivers/net/e1000/e1000_hw.h - 1.5 linux/drivers/usb/class/audio.c - 1.8 linux/drivers/usb/input/Config.help - 1.5 linux/drivers/usb/core/devio.c - 1.10 linux/drivers/usb/core/usb.c - 1.21 linux/drivers/base/sys.c - 1.5 linux/drivers/base/power.c - 1.6 linux/drivers/base/base.h - 1.9 linux/drivers/net/e1000/e1000_hw.c - 1.5 linux/drivers/usb/input/Config.in - 1.6 linux/drivers/usb/net/pegasus.h - 1.8 linux/mm/readahead.c - 1.10 linux/drivers/isdn/i4l/isdn_ppp.h - 1.4 linux/drivers/isdn/i4l/isdn_ppp.c - 1.10 linux/drivers/isdn/i4l/isdn_net.h - 1.9 linux/drivers/isdn/i4l/isdn_net.c - 1.9 linux/drivers/isdn/i4l/isdn_common.h - 1.6 linux/drivers/isdn/i4l/isdn_bsdcomp.c - 1.2 linux/drivers/isdn/i4l/Makefile - 1.6 linux/arch/x86_64/mm/modutil.c - 1.2 linux/drivers/block/umem.c - 1.14 linux/drivers/usb/host/uhci-debug.c - 1.3 linux/drivers/usb/host/uhci-hcd.c - 1.12 linux/drivers/usb/host/uhci-hcd.h - 1.4 linux/arch/i386/pci/i386.c - 1.3 linux/net/bluetooth/l2cap.c - 1.5 linux/net/bluetooth/hci_event.c - 1.4 linux/net/bluetooth/hci_conn.c - 1.4 linux/drivers/bluetooth/hci_h4.c - 1.5 linux/init/Makefile - 1.9 linux/include/asm-generic/siginfo.h - 1.4 linux/drivers/char/drm/sis_ds.c - 1.2 linux/drivers/base/bus.c - 1.7 linux/drivers/base/driver.c - 1.6 linux/fs/mpage.c - 1.12 linux/Documentation/networking/e100.txt - 1.2 linux/arch/ppc64/lib/copyuser.S - 1.3 linux/drivers/usb/core/message.c - 1.10 linux/drivers/usb/host/ohci-sa1111.c - 1.7 linux/arch/i386/kernel/cpu/amd.c - 1.6 linux/arch/x86_64/ia32/ipc32.c - 1.3 linux/drivers/input/serio/sa1111ps2.c - 1.3 linux/security/security.c - 1.3 linux/security/dummy.c - 1.4 linux/security/capability.c - 1.4 linux/drivers/serial/Makefile - 1.4 linux/drivers/serial/8250_pnp.c - 1.2 linux/include/linux/serial_core.h - 1.5 linux/include/linux/security.h - 1.4 linux/arch/arm/def-configs/lubbock - 1.3 linux/fs/aio.c - 1.8 linux/drivers/base/class.c - 1.2 linux/net/sctp/associola.c - 1.4 linux/net/sctp/bind_addr.c - 1.4 linux/net/sctp/input.c - 1.4 linux/net/sctp/output.c - 1.3 linux/net/sctp/outqueue.c - 1.5 linux/include/net/sctp/sm.h - 1.4 linux/net/sctp/sm_make_chunk.c - 1.5 linux/net/sctp/sm_sideeffect.c - 1.6 linux/net/sctp/sm_statefuns.c - 1.5 linux/include/net/sctp/structs.h - 1.5 linux/net/sctp/sm_statetable.c - 1.4 linux/net/sctp/socket.c - 1.6 linux/arch/um/Makefile - 1.6 linux/arch/um/drivers/ubd_kern.c - 1.6 linux/arch/sparc64/vmlinux.lds.S - 1.2 linux/arch/sparc/vmlinux.lds.S - 1.2 linux/arch/ppc/vmlinux.lds.S - 1.3 linux/arch/ppc/boot/include/mpc10x.h - 1.2 linux/drivers/base/platform.c - 1.3 linux/arch/ppc/boot/of1275/Makefile - 1.2 linux/mm/madvise.c - 1.2 linux/arch/ppc/boot/openfirmware/Makefile - 1.3 linux/drivers/isdn/i4l/isdn_ciscohdlck.c - 1.3 linux/drivers/usb/misc/usbtest.c - 1.3 linux/drivers/scsi/aacraid/aachba.c - 1.2 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.3 linux/net/bluetooth/rfcomm/tty.c - 1.4 linux/net/bluetooth/rfcomm/sock.c - 1.4 linux/net/bluetooth/rfcomm/core.c - 1.4 linux/net/bluetooth/bnep/sock.c - 1.3 linux/net/bluetooth/bnep/core.c - 1.3 linux/net/bluetooth/bnep/crc32.h - 1.2 linux/net/bluetooth/bnep/crc32.c - 1.2 linux/net/bluetooth/bnep/bnep.h - 1.2 linux/net/bluetooth/bnep/Makefile - 1.3 linux/include/net/bluetooth/rfcomm.h - 1.3 linux/net/sunrpc/svcauth_unix.c - 1.2 linux/fs/nfsd/nfs4xdr.c - 1.2 linux/fs/nfsd/nfs4proc.c - 1.2 linux/net/sunrpc/cache.c - 1.2 linux/arch/ppc/configs/cedar_defconfig - 1.2 linux/include/linux/nfsd/xdr4.h - 1.2 linux/include/linux/sunrpc/cache.h - 1.2 linux/fs/nfs/nfs4xdr.c - 1.2 linux/drivers/char/tipar.c - 1.2 linux/fs/afs/cmservice.c - 1.2 linux/include/asm-x86_64/proto.h - 1.2 linux/net/ipv4/ip_proc.c - 1.2 linux/arch/x86_64/kernel/reboot.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 21 12:08:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 12:08:04 -0700 (PDT) Received: from imf09bis.bellsouth.net (mail309.mail.bellsouth.net [205.152.58.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LJ82uR005919 for ; Mon, 21 Oct 2002 12:08:02 -0700 Received: from Mother2 ([66.156.2.239]) by imf09bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021021190940.IBWG24556.imf09bis.bellsouth.net@Mother2> for ; Mon, 21 Oct 2002 15:09:40 -0400 Date: Mon, 21 Oct 2002 15:07:55 -0400 From: Greg Freemyer Subject: re: [Bug 184] xfs_force_shutdown called on lvm-snapshot To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021021190940.IBWG24556.imf09bis.bellsouth.net@Mother2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9LJ82uR005929 X-archive-position: 1140 X-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 >> http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 >> ------- Additional Comments From sgi@debian.franken.de 2002-10-19 02:35 >> ------- >> What I did was like this: >> lvcreate -n root-snap -L 512m /dev/master/root-xfs >> lvcreate -n var-snap -L 512m /dev/master/var-xfs >> lvcreate -n home-snap -L 512m /dev/master/home-xfs SInce you are creating snapshots, I assume you mean like: lvcreate -s -n root-snap -L 512m /dev/master/root-xfs lvcreate -s -n var-snap -L 512m /dev/master/var-xfs lvcreate -s -n home-snap -L 512m /dev/master/home-xfs or lvcreate --snapshot -n root-snap -L 512m /dev/master/root-xfs lvcreate --snapshot -n var-snap -L 512m /dev/master/var-xfs lvcreate --snapshot -n home-snap -L 512m /dev/master/home-xfs If you left off the -s or --snapshot option, it is not surprising you are having problems. Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Oct 21 12:19:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 12:19:35 -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 g9LJJWuR007017 for ; Mon, 21 Oct 2002 12:19:33 -0700 Received: (qmail 5413 invoked by uid 1000); 21 Oct 2002 17:08:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Oct 2002 17:08:08 -0000 Date: Mon, 21 Oct 2002 20:08:08 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: uid64 quota and XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1141 X-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 Is there somebody here that runs a XFS with quota and lots of uid on files ? (>64k users, arround 200-300k) What would be the problems in such a situation ? I mean do I need special glibc? Special kernel ? Special tools ? What software may run in trouble with that ? 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 21 12:58:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 12:58:06 -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 g9LJw4uR010475 for ; Mon, 21 Oct 2002 12:58:04 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id C00651E2F6A; Mon, 21 Oct 2002 12:58:04 -0700 (PDT) Date: Mon, 21 Oct 2002 12:58:04 -0700 From: Chris Wedgwood To: Mihai RUSU Cc: Linux XFS List Subject: Re: uid64 quota and XFS Message-ID: <20021021195804.GA20871@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: 1142 X-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 21, 2002 at 08:08:08PM +0300, Mihai RUSU wrote: > Is there somebody here that runs a XFS with quota and lots of uid on > files ? (>64k users, arround 200-300k) I don't but I did test this once... > What would be the problems in such a situation? It should work, it's not hard to test anyhow. > I mean do I need > special glibc? glibc-2.2.x or later should support 32-bit UIDs (subject says uid64, XFS doesn't have this and I'm not sure you need it). > Special kernel? Any recent 2.4.x or 2.5.x kernel should work. > Special tools ? What software may run in trouble with that ? Make sure the tools and utilities out there that are quota aware are linked against a recent glibc. Pretty much anything less that a year or two old should work. I would just make a quick test setup if you have time and test things. It more important to test the applications you will likely run than the 'theoretical' issues I mention above. --cw From owner-linux-xfs@oss.sgi.com Mon Oct 21 13:55:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 13:55:22 -0700 (PDT) Received: from smtp4.cp.tin.it (vsmtp4.tin.it [212.216.176.224]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LKtJuR019351 for ; Mon, 21 Oct 2002 13:55:20 -0700 Received: from ibm300gl (212.171.167.74) by smtp4.cp.tin.it (6.5.029) id 3D9AD4B0006F48E9 for linux-xfs@oss.sgi.com; Mon, 21 Oct 2002 22:43:06 +0200 From: "Fabio Baiocco" To: Subject: Help with Xfs support for RH Kernel 2.4.18-17.7x Date: Mon, 21 Oct 2002 22:41:03 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-archive-position: 1143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fabio.baiocco@tin.it Precedence: bulk X-list: linux-xfs I use a RH 7.2 with XFS filesystem but i have a problem in applying the patch to the new kernel disposable in Red Hat Network 2.4.18-17.7x. Will a "contributed" kernel be realized? Or can someone help me in applying this patch to the kernel. What I should do? From owner-linux-xfs@oss.sgi.com Mon Oct 21 13:59:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 13:59:57 -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 g9LKxtuR020077 for ; Mon, 21 Oct 2002 13:59:55 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA00468; Mon, 21 Oct 2002 15:59:49 -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 PAA19473; Mon, 21 Oct 2002 15:59:49 -0500 (CDT) Subject: Re: Help with Xfs support for RH Kernel 2.4.18-17.7x From: Eric Sandeen To: Fabio Baiocco 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: 21 Oct 2002 15:55:36 -0500 Message-Id: <1035233736.30956.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1144 X-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 think Christoph is already working on a merge, if you can wait a few days. -Eric On Mon, 2002-10-21 at 15:41, Fabio Baiocco wrote: > I use a RH 7.2 with XFS filesystem but i have a problem in applying the > patch to the new kernel disposable in Red Hat Network 2.4.18-17.7x. > Will a "contributed" kernel be realized? > Or can someone help me in applying this patch to the kernel. What I should > do? > -- 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 21 14:04:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 14:04:32 -0700 (PDT) Received: from morpheus.matrix.com (193-153-176-50.uc.nombres.ttd.es [193.153.176.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LL4RuR021122 for ; Mon, 21 Oct 2002 14:04:28 -0700 Received: (qmail 894 invoked by uid 1000); 21 Oct 2002 21:05:22 -0000 From: yoros@wanadoo.es Date: Mon, 21 Oct 2002 23:05:22 +0200 To: linux-xfs Subject: A little question Message-ID: <20021021210522.GB787@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sory, I have received a mail and I think it is spam. I want to know exactly because it is in German and I don't know if it is spam or just a language error of the sender (sometimes it happend). If the sender is reading this e-mail, please =BFcan you answer me? Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9tGwSWIvihXTx06wRAnpMAJ9VNDhmYKgCeDXRDD64bN4GlgwRzQCgqKLB r6DrRk+EgejyhM0JVrWAktg= =K3Og -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-linux-xfs@oss.sgi.com Mon Oct 21 14:49:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 14:49:19 -0700 (PDT) Received: from sm01 (petradistributors.com [209.197.205.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LLnEuR025212 for ; Mon, 21 Oct 2002 14:49:16 -0700 Received: from unknown Date: Wed, 16 Oct 2002 08:32:14 -0600 Message-Id: <200210161432.g9GEWEXu015975@sm01> Errors: bdmail@bcdwest.com From: "Smart Buy's On WEB" To: OPT in List Subject: Factory Quality Printer Cartridges @ up to 60% Discounts MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Disposition: inline; filename="filename.html" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sm01 id g9GEWEXu015975 X-archive-position: 1146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bdmail@bcdwest.com Precedence: bulk X-list: linux-xfs October 16, 2002
October 16, 2002   = ;   
BCDWest Home   LaserJet=20 Toner   InkJet=20 Cartridges   Copier/Fax=20 Accessories


Save Up To 60% On Quality
ISO-9000 Certified Pri= nter=20 Cartridges

Quality=20 is a way of life at BCD West.  Our Research and Development = engineers=20 perform exhaustive tests on replacement parts and toner, car= efully=20 measuring components for maximum reliability, yield and imag= e quality,=20 then selecting only the best for each cartridge type.  = Our dedicated=20 quality engineers regularly perform random test, evaluating cartr= idges=20 against the toughest standards in the industry and looking for ne= w ways=20 to improve performance.  They also benchmark our cartridges = against=20 our competitor's products, ensuring that when it comes to quality= we continue=20 to lead the industry. 

At the end of the assembly line, every cartridge undergoes a deta= iled,=20 multi-page print test.  Those that pass this rigorous proces= s are=20 polished, sealed and boxed.

We are proud of each cartridge we make, and are gratified that cu= stomers=20 trust us with their printing needs.  We pull out all the sto= ps to=20 build the best and we are committed to put our customers first.

You=20 may order by e-mail at barrysr= @bcdwest.com=20 (there is no minimum order), go to our web page at BCDWest.com or call me at our = toll free=20 # 866-655-3475 ext. #61.  I will be happy to send out via = e-mail=20 our complete price list in an Excel spreadsheet. I sincerely ho= pe that=20 in the future we will have the privilege of supplying you with = our products.=20 If you wish to continue to receive our specials Please Click he= re to=20 SUBSCRIBE<= /A>. =20

Yours very truly,

Barry C Deuschle, Sr.
BCD TECHNOLOGIES WEST INC.
1535 OAK INDUSTRIAL LANE SUITE A
CUMMING, GA 30041
866-655-3475 ext. # 61

= If you have=20 received this message in error please accept our apologies.....= ...to=20 be removed simplyUn= -Subscribe=20 !
This is not SPAM under the Federal Regulatory laws of the Unite= d States,=20 we have included contact info and measures to be removed !
This message is being sent to you in compliance with the Federa= l legislation=20 for commercial e-mail !
(H.R.4176 - SECTION 101 Paragraph(e)(1)(A)) AND Bills.1618TITLE= III=20 passed by the 105th U.S. Congress.

100%=20 Guaranteed!
=A92002 BCDWest, Inc. All rights=20 reserved.
From owner-linux-xfs@oss.sgi.com Mon Oct 21 15:03:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 15:03:06 -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 g9LM31uR026722 for ; Mon, 21 Oct 2002 15:03:03 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8D8FB2FA72 for ; Mon, 21 Oct 2002 15:03:00 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id EA07D2FA72 for ; Mon, 21 Oct 2002 15:02:59 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 9612C1967B for ; Mon, 21 Oct 2002 15:02:49 -0700 (PDT) Subject: Re: v1.2 installer crash From: Florin Andrei To: linux-xfs In-Reply-To: <1035221912.25622.58.camel@rose.americas.sgi.com> References: <1035016560.1787.1.camel@stantz.corp.sgi.com> <1035221912.25622.58.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Oct 2002 15:02:49 -0700 Message-Id: <1035237769.16521.271.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1147 X-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 Mon, 2002-10-21 at 10:38, Russell Cattelan wrote: > It is very strange that the installer is doing lvm stuff then. > Did you have any lvm partitions at one point? No. The machine was previously installed with RH 7.3 XFS-enabled (the installer from oss.sgi.com). I just tried a format + reinstall "upgrade". It didn't had any LVM stuff, just plain partitions on regular SCSI drives. > The installer might be > discovering something it shouldn't and trying to deal with it. > You might want to wipe all partition information before starting the > install. > > It's also possible anaconda is incorrectly identifying xfs partitions as > lvm partitions, but that's a bug in anaconda. > > > On Sat, 2002-10-19 at 03:36, Florin Andrei wrote: > > Just a plain SGI1200, with 4xSCSI. I'm not sure what vgchange means. > > > > BTW, the plain RH8.0 installer worked without any problems. > > > > On Fri, 2002-10-18 at 19:19, Eric Sandeen wrote: > > > Did you have LVM on this machine? > > > > > > Looks like it failed because "vgchange" failed... > > > > > > -Eric > > > > > > On 18 Oct 2002, Florin Andrei wrote: > > > > > > > The RH8.0 installer (1.2pre) crashed. I didn't do any of the "forbidden" > > > > things mentioned in the README (text install, upgrade, use grub) yet it > > > > crashed. > > > > I attached the crash dump. > > > > > > > > The system is a SGI1200. > > > > I cannot repeat the experiment, because the machine is not available > > > > anymore. > > > > > > > > -- > > > > Florin Andrei > > > > > > > > Writing a book on wireless security > > > > is like writing a book on safe skydiving. > > > > > > > > > > > > -- > > Florin Andrei > > > > Writing a book on wireless security > > is like writing a book on safe skydiving. > > > > > -- Florin Andrei Writing a book on wireless security is like writing a book on safe skydiving. From owner-linux-xfs@oss.sgi.com Mon Oct 21 16:46:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 16:46:35 -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 g9LNkVuR001687 for ; Mon, 21 Oct 2002 16:46:32 -0700 Received: (qmail 23740 invoked from network); 21 Oct 2002 23:46:29 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 21 Oct 2002 23:46:29 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DB2A0300B3D; Tue, 22 Oct 2002 09:46:26 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 746EC108F; Tue, 22 Oct 2002 09:46:26 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: nospam@ocs.com.au To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: A little question In-reply-to: Your message of "Mon, 21 Oct 2002 23:05:22 +0200." <20021021210522.GB787@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Oct 2002 09:46:21 +1000 Message-ID: <6536.1035243981@ocs3.intra.ocs.com.au> X-archive-position: 1148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam@ocs.com.au Precedence: bulk X-list: linux-xfs On Mon, 21 Oct 2002 23:05:22 +0200, yoros@wanadoo.es wrote: >Sory, I have received a mail and I think it is spam. I want to know >exactly because it is in German and I don't know if it is spam or just a >language error of the sender (sometimes it happend). If the sender is >reading this e-mail, please =BFcan you answer me? From my spam collection for this list, if the German mail contains 'www.travel24.com', 'www.julia.5xx.net', 'www.singles-contacts.com' then it is spam. From owner-linux-xfs@oss.sgi.com Mon Oct 21 16:56:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 16:56:27 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LNuOuR002792 for ; Mon, 21 Oct 2002 16:56:25 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9LNuKf13682; Mon, 21 Oct 2002 19:56:20 -0400 Message-ID: <3DB49424.9E4CAC0F@splentec.com> Date: Mon, 21 Oct 2002 19:56:20 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs , Eric Sandeen Subject: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Problem: on an SMP system, BANG#@!, the unthinkable happens. Solution: never sleep when holding a lock. This patch applies to CVS code as of about 18:30 EDT on Mon Oct 21 (today), and is self-explanatory. This patch fixes the problem of the mount going into D state indefinitely when the RAID is syncing and mount is run right after mkfs.xfs (from shell script, no sleep between, low system load, SMP). If you know of similar incidents in other parts of the code those should be fixed, probably ASAP. Please apply, -- Luben --- linux/fs/xfs/pagebuf/page_buf.c.orig Mon Oct 21 19:13:01 2002 +++ linux/fs/xfs/pagebuf/page_buf.c Mon Oct 21 19:13:05 2002 @@ -710,7 +710,7 @@ pb_resv_bh_cnt++; if (waitqueue_active(&pb_resv_bh_wait)) { - wake_up(&pb_resv_bh_wait); + wake_up_sync(&pb_resv_bh_wait); } } From owner-linux-xfs@oss.sgi.com Mon Oct 21 17:15:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 17:15:48 -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 g9M0FjuR004989 for ; Mon, 21 Oct 2002 17:15:46 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA50625; Mon, 21 Oct 2002 19:15:41 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-56.corp.sgi.com [134.15.64.56]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA93572; Mon, 21 Oct 2002 19:15:38 -0500 (CDT) Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c From: Stephen Lord To: Luben Tuikov Cc: linux-xfs , Eric Sandeen In-Reply-To: <3DB49424.9E4CAC0F@splentec.com> References: <3DB49424.9E4CAC0F@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 21 Oct 2002 19:11:23 -0500 Message-Id: <1035245485.1969.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1150 X-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-21 at 18:56, Luben Tuikov wrote: > Problem: on an SMP system, BANG#@!, the unthinkable happens. > Solution: never sleep when holding a lock. Yep, this is definitely a bug, you must be pushing memory on the system pretty hard to hit it, memory allocations are failing at the point it happens. Fix should go in shortly. Thanks, Steve From owner-linux-xfs@oss.sgi.com Mon Oct 21 23:21:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 23:22:00 -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 g9M6LuuR028881 for ; Mon, 21 Oct 2002 23:21:57 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 3BEE5AC3A; Tue, 22 Oct 2002 08:16:56 +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 DC5DB190A9; Tue, 22 Oct 2002 08:16:49 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 5D30330881D; Tue, 22 Oct 2002 08:21:47 +0200 (CEST) Message-ID: <3DB4EE7B.998FCADA@ch.sauter-bc.com> Date: Tue, 22 Oct 2002 08:21:47 +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: Luben Tuikov Cc: linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1151 X-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 Luben Tuikov schrieb: > > Problem: on an SMP system, BANG#@!, the unthinkable happens. > Solution: never sleep when holding a lock. > > This patch applies to CVS code as of about 18:30 EDT > on Mon Oct 21 (today), and is self-explanatory. > > This patch fixes the problem of the mount going into D state > indefinitely when the RAID is syncing and mount is run > right after mkfs.xfs (from shell script, no sleep between, > low system load, SMP). I've had some troubles with one of my servers after a failing disk from the SoftRAID. IIRC it was like this: I replaced the broken disk and added it to the RAID volume using a boot CD. Before the volume was synced, I rebootet. The box came up but hung when it tried to mount some XFS volumes on the syncing RAID. My solution was to boot with init=/bin/sh, wait for the sync to complete, and then do a normal boot. Could this be the bug you found here? Simon > > If you know of similar incidents in other parts of the code > those should be fixed, probably ASAP. > > Please apply, > -- > Luben > > --- linux/fs/xfs/pagebuf/page_buf.c.orig Mon Oct 21 19:13:01 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c Mon Oct 21 19:13:05 2002 > @@ -710,7 +710,7 @@ > pb_resv_bh_cnt++; > > if (waitqueue_active(&pb_resv_bh_wait)) { > - wake_up(&pb_resv_bh_wait); > + wake_up_sync(&pb_resv_bh_wait); > } > } From owner-linux-xfs@oss.sgi.com Mon Oct 21 23:31:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 23:31:32 -0700 (PDT) Received: from prontomail.com (host.190.123.23.62.rev.coltfrance.com [62.23.123.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M6VQuR029788 for ; Mon, 21 Oct 2002 23:31:28 -0700 Received: from 10.59.32.231 ([10.59.32.231]) by symail.kustanai.co.kr with NNFMP; 22 Oct 2002 00:21:32 +0100 Received: from [121.149.30.52] by n9.groups.huyahoo.com with NNFMP; Tue, 22 Oct 2002 01:18:09 -0600 Received: from 196.193.156.220 ([196.193.156.220]) by da001d2020.loxi.pianstvu.net with QMQP; Mon, 21 Oct 2002 19:14:46 +1100 Reply-To: Message-ID: <016b81c82d3c$1765c8d4$4ea24cd5@xtdjtm> From: To: everybody@oss.sgi.com Subject: BIZOPP! Iskoristite svoje racunalo za dodatnu zaradu! 7455gLDu7--9 Date: Mon, 21 Oct 2002 21:56:20 +0800 MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: eGroups Message Poster Importance: Normal X-archive-position: 1152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: blanka_p@prontomail.com Precedence: bulk X-list: linux-xfs ENGLISH TEXT AT THE BOTTOM: http://www.megaone.com/lindach/bizeng.html Postovani, Ovu poruku primit cete samo jednom i ako vas ova ponuda ne interesira, ispricavamo se i nadalje Vam necemo slati obavijesti. U ovoj ponudi nudimo vam mogucnost novog posla u Hrvatskoj, Srbiji, Bosni...te dobre zarade kroz rad na Internetu. Buduci da se radi o ozbiljnom poslu, od kandidata se ocekuje: - punoljetnost, tj. min 18 godina zivota - pristup Internetu - zelja za timskim radom - poznavanje osnova engleskog (nije apsolutni uvjet) Zanima li Vas mogucnost dobre zarade i dobar globalni biznis, upisite svoj mail bez ikakve obaveze na adresi: http://www.megaone.com/lindach/biz.html Nakon Vase prijave kontaktirat cemo Vas u roku od 24 sata s detaljnim obavijestima. Srdacan pozdrav u nadi daljnje suradnje Tihomir Dijanic http://www.megaone.com/lindach/biz.html ********************************* G'Day ! You are receiving this letter because you have expressed an interest in receiving information about online business opportunities. If this is erroneous then please accept my most sincere apology. This really works, don't make the same mistake I made. I deleted this twice before finally giving it a try.. Give it a try!! You will be glad you did. The ad is below:- A NETWORK MARKETING OPPORTUNITY WITH A GUARANTEE!! TRY It BEFORE YOU BUY IT! How would you like to know that you have an existing downline and team in place to continue to help you develop a network BEFORE you ever sign up or invest a penny? How would you like to know that you can earn an easy GUARANTEED Commission check coming to you EVERY month that just keeps getting bigger??? Unique TEAM concept to help you to build a network. There is absolutely no risk to get involved and no cost to join No hype - this is for real and we can prove it. ALL new members that come into the club COMPANY WIDE will go under YOU. A true VERTICAL downline. Get your FREE membership now and WATCH what happens !!!!! As a FREE Club Member, you get rebates on your purchases at the affiliate stores located in the Mall, over 150 well known stores. LIMITED TIME offer FREE SOFTWARE That You Can Start Using Right Now To Bring Instant Visitors To ANY Web Site ! YOU HAVE NOTHING to LOSE and POTENTIALLY a LOT to GAIN. http://www.megaone.com/lindach/bizeng.html Kind regards, Tihomir Dijanic http://www.megaone.com/lindach/bizeng.html ------------------------------------------------------------------- Mark Joyner`s new BOMBSHELLS in PRE-LAUNCH: http://www.gmktgb.com/page/tobi/ FREE CLASSIFIED ADS - Post your classified for the world to see! http://pub25.bravenet.com/classified/show.php?usernum=2135942814 GET FREE VISITORS! http://www.nomorehits.com/cgi-bin/start.cgi?referrer=medvescak 500 visitors4join! - http://www.trafficswarm.com/go.cgi?6948 -------------------------------------------------------------------- This is a one time mailing and you will not be contacted again and though it is not necessary to request removal, you may do so by sending an email to: mailto:blanka_p@prontomail.com?subject=Remove 7495aqzG0-448oHLq1742oYfy5-402jtyI5370l36 From owner-linux-xfs@oss.sgi.com Mon Oct 21 23:54:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Oct 2002 23:54:21 -0700 (PDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M6sHuR031557 for ; Mon, 21 Oct 2002 23:54:18 -0700 Received: from g8sbr.gppng01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 22 Oct 2002 08:53:31 +0200 Received: by G8SBR.gppng01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 08:53:31 +0200 Message-Id: <43E285EFC5BED511965A0800060DC620013326DF@U8SN4.gppng01.telekom.de> From: "Geiger, Michael" To: sandeen@sgi.com Cc: linux-xfs@oss.sgi.com Subject: AW: could not pre-alloc tmp space Date: Tue, 22 Oct 2002 08:53:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Geiger@telekom.de Precedence: bulk X-list: linux-xfs > As Chris pointed out, you actually need newer tools... > xfsdump >= 2.2.2. > > I'll make sure that's available on the ftp site today. > > -Eric Thank you Eric, after upgrading to 2.2.2 the problem is gone! Michael From owner-linux-xfs@oss.sgi.com Tue Oct 22 00:27:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 00:27:53 -0700 (PDT) Received: from web15206.mail.bjs.yahoo.com ([61.135.128.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M7RhuR001081 for ; Tue, 22 Oct 2002 00:27:46 -0700 Message-ID: <20021022072738.85687.qmail@web15206.mail.bjs.yahoo.com> Received: from [210.72.245.11] by web15206.mail.bjs.yahoo.com via HTTP; Tue, 22 Oct 2002 15:27:38 CST Date: Tue, 22 Oct 2002 15:27:38 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: the oops under heavy load To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 1154 X-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 hi: xfs developers. when I test xfs under heavy load, I found an oops at the function unlock_page(). After study the trace of oops, I found that the oops happened here. (fs/xfs/pagebuf/page_buf.c 562 ) if (!pb->pb_locked) { for (pi = 0; pi < page_count; pi++) { unlock_page(pb->pb_pages[pi]); } } I investigate the src code. I found that when the memory is tight, the function (_pagebuf_lookup_pages) did not return and it also did not check the pointer pb->pb_pages[pi], so if the memory is tight, pb->pb_pages[pi] maybe NULL, at that time, if we called unlock_page(pb->pb_pages[pi]), oops will happen. _________________________________________________________ Do You Yahoo!? "愿意花几分钟来改善您的雅虎电邮服务吗？" http://sweepstakes.yahoo.com/email_usage From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:01:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:01:23 -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 g9MC1IuR023257 for ; Tue, 22 Oct 2002 05:01:19 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 183xio-0006MO-00; Tue, 22 Oct 2002 13:01:18 +0100 Date: Tue, 22 Oct 2002 13:01:18 +0100 From: Christoph Hellwig To: tom wang Cc: linux-xfs@oss.sgi.com Subject: Re: the oops under heavy load Message-ID: <20021022130118.A24163@infradead.org> References: <20021022072738.85687.qmail@web15206.mail.bjs.yahoo.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: <20021022072738.85687.qmail@web15206.mail.bjs.yahoo.com>; from wddi_1976@yahoo.com.cn on Tue, Oct 22, 2002 at 03:27:38PM +0800 X-archive-position: 1155 X-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 Tue, Oct 22, 2002 at 03:27:38PM +0800, tom wang wrote: > hi: > xfs developers. > > when I test xfs under heavy load, I found an oops at > the function unlock_page(). After study the trace of > oops, > I found that the oops happened here. > (fs/xfs/pagebuf/page_buf.c 562 ) > > > if (!pb->pb_locked) { > for (pi = 0; pi < page_count; pi++) { > unlock_page(pb->pb_pages[pi]); > } > } > > I investigate the src code. I found that when the > memory is tight, > the function (_pagebuf_lookup_pages) did not return > and it also did not check > the pointer pb->pb_pages[pi], so if the memory is > tight, pb->pb_pages[pi] > maybe NULL, at that time, if we called > unlock_page(pb->pb_pages[pi]), oops > will happen. You're right. I'll add an check to only unlock if the page is actually present. Thanks a lot for finding that bug. From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:12:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:12:21 -0700 (PDT) Received: from mydomain.com (213-96-189-190.uc.nombres.ttd.es [213.96.189.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MCBiuR024851 for ; Tue, 22 Oct 2002 05:11:55 -0700 Message-Id: <200210221211.g9MCBiuR024851@oss.sgi.com> From: "Be on ALL the Major Search Engines" To: "Linux-xfs" Subject: In just 48 HOURS!!! Guaranteed! Date: Tue, 22 Oct 2002 14:12:00 +0200 MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High Reply-To: "Be on ALL the Major Search Engines" Organization: WWC X-Mailer: Internet Mail Service Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 2450 X-archive-position: 1156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: goodmansis@freeuk.com Precedence: bulk X-list: linux-xfs When you search for your website on many of the search engines you cannot find it or when you do you find it is on the back pages! Can this be changed? YES! " You have your web site designed and have sorted out the maintenance and waiting for the business to roll in, but there's one small problem.... No one knows!" You need a professional company to do itt. Getting onto the worlds search engines and high in their listings doesn't just happen. You have to be put there! Your web site designer and your host are NOT responsible for getting your web site seen! Yes, they may submit your site to a few search engines periodically but to stay on the TOP of the search engines is an aggressive business. The fact is that over 80 million real people use the search engines every day. Search engines are the most effective way of reaching your customers. So you must be on them! We guarantee to give your web site the exposure that it deserves both locally and globally. Using the expertise of years in the industry our aim is to get you to the top of the search engine listings and then keep you there. Guaranteed! To Book our Service Simply PRESS this BOOK NOW! Button and we can begin submitting your web site to the worlds search engines today! giff image We will submit your web site to the top search engines every two days. We guarantee that your web site will be on them within 48 Hours and then we will submit our web site to another 250 top search engines and directories every 30 days. So once we have got you onto the search engines you will stay on them! BUT we do more: We will submit your site using the most effective meta tags and keywords. How do we know which are the most effective ones to use on your web site? Our team of experts will examine your website and see what meta-tags and keywords you are presently using and then replace them with keywords and meta-tags from the top companies in your category. If it works for them it will work for you! See our testimonials. Search Engine Facts Testimonials Our Money Back Guarantee Major Search Engine Information About Goodman Systems, Inc Go to Goodman Systems website... Click the button below to book now: If you have any questions please send us an mail and one of our technical team will be happy to help you: support@goodmansystems.com Goodman Systems, Inc The leader in Professional Web Site Submission [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:25:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:25:31 -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 g9MCPTuR027265 for ; Tue, 22 Oct 2002 05:25:29 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA53811; Tue, 22 Oct 2002 07:25:27 -0500 (CDT) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-52.corp.sgi.com [134.15.64.52]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA26383; Tue, 22 Oct 2002 07:25:24 -0500 (CDT) Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c From: Stephen Lord To: Luben Tuikov Cc: linux-xfs , Eric Sandeen In-Reply-To: <3DB49424.9E4CAC0F@splentec.com> References: <3DB49424.9E4CAC0F@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 22 Oct 2002 07:21:10 -0500 Message-Id: <1035289272.9684.13.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1157 X-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-21 at 18:56, Luben Tuikov wrote: > Problem: on an SMP system, BANG#@!, the unthinkable happens. > Solution: never sleep when holding a lock. > > This patch applies to CVS code as of about 18:30 EDT > on Mon Oct 21 (today), and is self-explanatory. > > This patch fixes the problem of the mount going into D state > indefinitely when the RAID is syncing and mount is run > right after mkfs.xfs (from shell script, no sleep between, > low system load, SMP). > > If you know of similar incidents in other parts of the code > those should be fixed, probably ASAP. Rethinking this, the wake_up does not actually sleep. All this change does is change it from waking all waiters on this lock to waking one of them. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:25:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:25:39 -0700 (PDT) Received: from rail.cita.utoronto.ca (rail.cita.utoronto.ca [128.100.76.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MCPbuR027358 for ; Tue, 22 Oct 2002 05:25:37 -0700 Received: from [128.100.76.25] (marmot.cita.utoronto.ca) by rail.cita.utoronto.ca id 13586; Tue, 22 Oct 2002 08:25:36 Date: Tue, 22 Oct 2002 08:25:36 -0400 From: Robin Humble To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.5.44 Message-ID: <20021022082536.A22529@marmot.cita.utoronto.ca> References: <200210211820.g9LIKtm25752@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210211820.g9LIKtm25752@jen.americas.sgi.com>; from lord@sgi.com on Mon, Oct 21, 2002 at 01:20:55PM -0500 X-archive-position: 1158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs On Mon, Oct 21, 2002 at 01:20:55PM -0500, Steve Lord wrote: > ... >linux/Makefile - 1.226 The root Makefile still says 2.5.43 - typo? cheers, robin ps. redhat 8.0 + 2.5.43-xfs seems prety stable under a home workstation type load to me :-) From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:34:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:34:22 -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 g9MCYKuR028749 for ; Tue, 22 Oct 2002 05:34:20 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA21995 for ; Tue, 22 Oct 2002 07:34: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 HAA30503 for ; Tue, 22 Oct 2002 07:34:17 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9MCUeC31534; Tue, 22 Oct 2002 07:30:40 -0500 Message-Id: <200210221230.g9MCUeC31534@jen.americas.sgi.com> Date: Tue, 22 Oct 2002 07:30:40 -0500 Subject: TAKE - bump makefile version number To: linux-xfs@oss.sgi.com X-archive-position: 1159 X-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 Missed this from the merge, rest of the makefile was fixed up. Date: Tue Oct 22 05:33:28 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:130706a linux/Makefile - 1.227 - bump to 2.5.44 From owner-linux-xfs@oss.sgi.com Tue Oct 22 05:56:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 05:56:33 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MCuVuR030700 for ; Tue, 22 Oct 2002 05:56:31 -0700 MIME-Version: 1.0 Subject: aic7xxx pairty error detected in data-in phase X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 22 Oct 2002 08:54:25 -0400 Message-ID: <5A2E4FE5C3D6544D94403072129E30D903A163@cli_exch_one.complexlit.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aic7xxx pairty error detected in data-in phase Thread-Index: AcJ5yia4sRiKrA+8QQG92C9Ga9nqmQ== From: "Brian Gulizia" To: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1459 X-archive-position: 1160 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Hi all, First, let me apologize if this has been addressed. I am currently running a Dell 1650 witth Redhat 7.3 & SGI's XFS 1.1. The Kernel is 2.4.18-4SGI_XFS_1.1smp. I have an adaptec 39160 card installed with 2 Maxtronic Arena Raid boxes attached, 1 to each channel (arena raid box is simply 14 IDE hard drives connected to a scsi backplane). I am receiving the following error in my messages log 4 times every second, filling up my var rapidly: ******** (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x4e) SCSIRATE(0xc2) No terminal CRC packet received. ********* I've been through the archives of this list, as well as having done searches on groups.google.com and have tried all of the suggestions mentioned. I have replaced the cable and I changed the memory out on the scsi card inside the raid box. The next step I was going to try was replacing the 39160 card, but found out there was a new aic7xxx driver available, as well as a new kernel rpm. As I am a relative Linux newbie, I spoke with Dell and they told me to load the new kernel, kernel-smp-2.4.18-17.7.x.i686.rpm. The problem is that this kernel does not support xfs, but it did in fact stop the message from occuring. We then tried to integrate the new aic7xxx driver into the xfs kernel with no luck. Has anyone else run into this problem? Do you have any suggestions? Was I doing something wrong? Thanks, Brian Gulizia [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Oct 22 06:21:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 06:21:26 -0700 (PDT) Received: from imf00bis.bellsouth.net (mail100.mail.bellsouth.net [205.152.58.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MDLOuR032704 for ; Tue, 22 Oct 2002 06:21:24 -0700 Received: from nec ([67.34.30.245]) by imf00bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021022132305.NQBN25430.imf00bis.bellsouth.net@nec> for ; Tue, 22 Oct 2002 09:23:05 -0400 Subject: $$-Discounted Gifts-$$ For the holidays To: linux-xfs@oss.sgi.com From: "Gifts to Go" Content-Type: multipart/related;type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C06B5E.74675200" Date: Tue, 22 Oct 2002 00:00:00 -0400 Message-Id: <20021022132305.NQBN25430.imf00bis.bellsouth.net@nec> X-archive-position: 1161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Gifts2gonow@bellsouth.net Precedence: bulk X-list: linux-xfs ------=_NextPart_000_0004_01C06B5E.74675200 Subject: $$-Discounted Gifts-$$ For the holidays To: linux-xfs@oss.sgi.com From: "Gifts to Go" Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C06B5E.74675200" Date: 10/22/2002X-Mailer: Spyder Mailer 1.2 =0D=0A=0D=0A=0D=0AUntitled=0D=0A=0D=0A=0D=0A

Neeed= =20a GREA= T=20gift?=20Choose=20from=20over=203,000=20unique=20gifts=20for=20al= l=20of=20=0D=0Alife's=20celebrations! Jewelry,=20fantasy=20sculptures,= =20home=20decor,=20garden=20=0D=0Aaccessories=20and=20much=20more.=20

=0D=0A

For=20a=2010= %=20discount=20=0D=0Aon=20your=20first=20order,=20use=20cod= e=20021016.   =20Gifts2gonow.com

=0D=0A

 

=0D=0A ------=_NextPart_000_0005_01C06B5E.74675200 Content-Type: text/plain Neeed aGREAT gift? Choose from over 3,000 unique gifts for all of life's celebrations!Jewelry, fantasy sculptures, home decor, garden accessories and much more. For a 10% discount on your first order, use code 021016. Gifts2gonow.com ------=_NextPart_000_0005_01C06B5E.74675200 Content-Type: text/html Content-Transfer-Encoding: quoted-printable =0D =0D =0D Untitled=0D =0D =0D

Neeed a GREAT gift? Choose from over 3,000 unique gifts for = all of =0D life's celebrations! Jewelry, fantasy sculptures, home decor, garden = =0D accessories and much more.

=0D

For a 10% d= iscount =0D on your first order, use code 021016.    Gifts2gonow.com

=0D

 

=0D ------=_NextPart_000_0005_01C06B5E.74675200-- ------=_NextPart_000_0004_01C06B5E.74675200-- From owner-linux-xfs@oss.sgi.com Tue Oct 22 06:24:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 06:24:17 -0700 (PDT) Received: from students.fct.unl.pt (students.fct.unl.pt [193.136.120.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MDOAuR000868 for ; Tue, 22 Oct 2002 06:24:14 -0700 Received: from localhost (pjsm@localhost) by students.fct.unl.pt (8.11.6/8.11.6) with ESMTP id g9MDO1h14187; Tue, 22 Oct 2002 14:24:01 +0100 X-Authentication-Warning: students.fct.unl.pt: pjsm owned process doing -bs Date: Tue, 22 Oct 2002 14:24:01 +0100 (WEST) From: Paulo Matos To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: RH 8.0 installer In-Reply-To: Message-ID: X-GPG-PUBLIC_KEY: http://students.fct.unl.pt/~pjsm/pjsm_fct.public.asc X-GPG-FINGRPRINT: 1024D/1DD3CA2F 5E95 9FD3 3435 A763 18E9 FB57 282B BCD7 1DD3 CA2F MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by students.fct.unl.pt id g9MDO1h14187 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9MDOFuR000870 X-archive-position: 1162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pjsm@fct.unl.pt Precedence: bulk X-list: linux-xfs Hi Eric! You stated before that RH7.3 installer was the last one you planed to do. Is this final? If so, can you give me some hints on doing that? I would like to do that for using it on my institution and if it will be stable enough to give it to the world. Regards, -- Paulo Matos ----------------------------------- ---------------------------------- |Sys & Net Admin | Servi鏾 de Inform醫ica | |Faculdade de Ci阯cias e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa | Fax: +351-21-2948548 | |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | ----------------------------------- ---------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 22 06:50:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 06:50:39 -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 g9MDoauR003102 for ; Tue, 22 Oct 2002 06:50:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA39671 for ; Tue, 22 Oct 2002 08:50:34 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA65533 for ; Tue, 22 Oct 2002 08:50:33 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g9ML5b507920 for linux-xfs@oss.sgi.com; Tue, 22 Oct 2002 17:05:37 -0400 Resent-Message-Id: <200210222105.g9ML5b507920@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA94750 for ; Tue, 22 Oct 2002 08:27:29 -0500 (CDT) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g9MDRPpx27457772 for ; Tue, 22 Oct 2002 06:27:27 -0700 (PDT) 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 g9MDQOUi001986 for ; Tue, 22 Oct 2002 15:26:24 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9MDQOQI001985 for hch@sgi.com; Tue, 22 Oct 2002 15:26:24 +0200 Date: Tue, 22 Oct 2002 15:26:24 +0200 Message-Id: <200210221326.g9MDQOQI001985@lab343.munich.sgi.com> Subject: TAKE - fix NULL pointer dereference in pagebuf To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 22 Oct 2002 17:05:37 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1163 X-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@sgi.com Precedence: bulk X-list: linux-xfs This should fix the bug reported by Tom Wang Date: Tue Oct 22 06:26:19 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:130709a linux/fs/xfs/pagebuf/page_buf.c - 1.68 - Check for pages beeing non-NULL before unlocking in From owner-linux-xfs@oss.sgi.com Tue Oct 22 07:52:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 07:52:17 -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 g9MEqFuR007200 for ; Tue, 22 Oct 2002 07:52:16 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA43412; Tue, 22 Oct 2002 09:52:13 -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 JAA66232; Tue, 22 Oct 2002 09:52:13 -0500 (CDT) Subject: Re: RH 8.0 installer From: Eric Sandeen To: Paulo Matos Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 22 Oct 2002 09:47:53 -0500 Message-Id: <1035298073.470.3.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 g9MEqGuR007219 X-archive-position: 1165 X-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 Someone has already done it, take a look in the XFS 1.2 prerelease directory. -Eric On Tue, 2002-10-22 at 08:24, Paulo Matos wrote: > Hi Eric! > > You stated before that RH7.3 installer was the last one you planed > to do. Is this final? If so, can you give me some hints on doing that? I > would like to do that for using it on my institution and if it will be > stable enough to give it to the world. > > Regards, > > -- > Paulo Matos > ----------------------------------- ---------------------------------- > |Sys & Net Admin | Servi鏾 de Inform醫ica | > |Faculdade de Ci阯cias e Tecnologia | Tel: +351-21-2948596 | > |Universidade Nova de Lisboa | Fax: +351-21-2948548 | > |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | > ----------------------------------- ---------------------------------- -- 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 22 07:51:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 07:52:01 -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 g9MEpuuR007122 for ; Tue, 22 Oct 2002 07:51:57 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA55858; Tue, 22 Oct 2002 09:51:55 -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 JAA83721; Tue, 22 Oct 2002 09:51:54 -0500 (CDT) Subject: Re: aic7xxx pairty error detected in data-in phase From: Eric Sandeen To: Brian Gulizia Cc: linux-xfs@oss.sgi.com In-Reply-To: <5A2E4FE5C3D6544D94403072129E30D903A163@cli_exch_one.complexlit.com> References: <5A2E4FE5C3D6544D94403072129E30D903A163@cli_exch_one.complexlit.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 22 Oct 2002 09:47:34 -0500 Message-Id: <1035298054.551.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1164 X-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 You might try the 2.4.18-14 kernel available in the XFS 1.2 prerelease, although this will be changing much more than just your scsi driver. A 2.4.18-17 kernel with xfs merged will probably be available from us in the not-so-distant future. -Eric On Tue, 2002-10-22 at 07:54, Brian Gulizia wrote: > Hi all, > > First, let me apologize if this has been addressed. > > I am currently running a Dell 1650 witth Redhat 7.3 & SGI's XFS 1.1. The Kernel is 2.4.18-4SGI_XFS_1.1smp. I have an adaptec 39160 card installed with 2 Maxtronic Arena Raid boxes attached, 1 to each channel (arena raid box is simply 14 IDE hard drives connected to a scsi backplane). > > I am receiving the following error in my messages log 4 times every second, filling up my var rapidly: > > ******** > (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x4e) SCSIRATE(0xc2) > No terminal CRC packet received. > ********* > > I've been through the archives of this list, as well as having done searches on groups.google.com and have tried all of the suggestions mentioned. I have replaced the cable and I changed the memory out on the scsi card inside the raid box. The next step I was going to try was replacing the 39160 card, but found out there was a new aic7xxx driver available, as well as a new kernel rpm. As I am a relative Linux newbie, I spoke with Dell and they told me to load the new kernel, kernel-smp-2.4.18-17.7.x.i686.rpm. The problem is that this kernel does not support xfs, but it did in fact stop the message from occuring. We then tried to integrate the new aic7xxx driver into the xfs kernel with no luck. > Has anyone else run into this problem? Do you have any suggestions? Was I doing something wrong? > Thanks, > Brian Gulizia > > > [[HTML alternate version deleted]] > -- 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 22 12:55:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 12:56:00 -0700 (PDT) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MJtwuR027374 for ; Tue, 22 Oct 2002 12:55:58 -0700 Received: from splentec.com ([24.43.191.127]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021022195459.SLK4551.fep02-mail.bloor.is.net.cable.rogers.com@splentec.com>; Tue, 22 Oct 2002 15:54:59 -0400 Message-ID: <3DB5AD3F.80402@splentec.com> Date: Tue, 22 Oct 2002 15:55:43 -0400 From: Luben Tuikov Organization: Splentec Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.43.191.127] using ID at Tue, 22 Oct 2002 15:54:59 -0400 X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: > On Mon, 2002-10-21 at 18:56, Luben Tuikov wrote: > >>Problem: on an SMP system, BANG#@!, the unthinkable happens. >>Solution: never sleep when holding a lock. >> >>This patch applies to CVS code as of about 18:30 EDT >>on Mon Oct 21 (today), and is self-explanatory. >> >>This patch fixes the problem of the mount going into D state >>indefinitely when the RAID is syncing and mount is run >>right after mkfs.xfs (from shell script, no sleep between, >>low system load, SMP). >> >>If you know of similar incidents in other parts of the code >>those should be fixed, probably ASAP. > > > Rethinking this, the wake_up does not actually sleep. All > this change does is change it from waking all waiters > on this lock to waking one of them. No! This is what wake_up_sync() does. wake_up() may reschedule on an SMP system, since the other CPUs may be able to get another task to run. This is why there are two different implementations wake_up() and wake_up_sync(). If you have 4 CPUs, 3 idle and call wake_up() why should the 3 idle CPUs _STAY_ idle, _until_ you (later) call schedule() and _then_ to schedule another task on the idle CPUs, and you to continue to go on, say if you were a SCHED_FIFO, or SCHED_OTHER... BTW, that the _whole_ point of SMP -- _symmetric_ MP. Bugs like this and the one recently found by Tom Wang an me, are elementary OS 101 and Programming 101. Maybe a major overhaul of the source should be done. Anyway, if you really DO THINK that you're right, maybe you should INSIST that the code is LEFT as it was, with a call to wake_up(). -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 13:00:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 13:00:54 -0700 (PDT) Received: from students.fct.unl.pt (students.fct.unl.pt [193.136.120.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MK0puR028102 for ; Tue, 22 Oct 2002 13:00:52 -0700 Received: from localhost (pjsm@localhost) by students.fct.unl.pt (8.11.6/8.11.6) with ESMTP id g9MK0lB00872; Tue, 22 Oct 2002 21:00:47 +0100 X-Authentication-Warning: students.fct.unl.pt: pjsm owned process doing -bs Date: Tue, 22 Oct 2002 21:00:47 +0100 (WEST) From: Paulo Matos To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: RH 8.0 installer In-Reply-To: <1035298073.470.3.camel@stout.americas.sgi.com> Message-ID: X-GPG-PUBLIC_KEY: http://students.fct.unl.pt/~pjsm/pjsm_fct.public.asc X-GPG-FINGRPRINT: 1024D/1DD3CA2F 5E95 9FD3 3435 A763 18E9 FB57 282B BCD7 1DD3 CA2F MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by students.fct.unl.pt id g9MK0lB00872 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9MK0ruR028103 X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pjsm@fct.unl.pt Precedence: bulk X-list: linux-xfs On 22 Oct 2002, Eric Sandeen wrote: sandee> Someone has already done it, take a look in the XFS 1.2 prerelease sandee> directory. You know who is doing it? I looked at Release-1.2pre1/installer/ annd he claims that there are some problems with text intall related to partitioning. I also noticed there is an empty Release-1.2pre2... Please send me the address where to report. Thanks again, -- Paulo Matos ----------------------------------- ---------------------------------- |Sys & Net Admin | Servi鏾 de Inform醫ica | |Faculdade de Ci阯cias e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa | Fax: +351-21-2948548 | |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | ----------------------------------- ---------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 22 13:02:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 13:02:50 -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 g9MK2muR028351 for ; Tue, 22 Oct 2002 13:02:49 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA56952; Tue, 22 Oct 2002 15:02:47 -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 PAA66923; Tue, 22 Oct 2002 15:02:47 -0500 (CDT) Subject: Re: RH 8.0 installer From: Eric Sandeen To: Paulo Matos 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: 22 Oct 2002 14:58:25 -0500 Message-Id: <1035316705.551.40.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1168 X-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 Yep, it's Russell Cattelan here at SGI, he originally posted the message that the installer was released, along with all the caveats. Feel free to just send bug reports (and patches...) to the list, though. 1.2pre2 will be populated when it's available... -Eric On Tue, 2002-10-22 at 15:00, Paulo Matos wrote: > On 22 Oct 2002, Eric Sandeen wrote: > > sandee> Someone has already done it, take a look in the XFS 1.2 prerelease > sandee> directory. > > You know who is doing it? I looked at Release-1.2pre1/installer/ > annd he claims that there are some problems with text intall related to > partitioning. I also noticed there is an empty Release-1.2pre2... -- 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 22 13:07:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 13:07:01 -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 g9MK6xuR029356 for ; Tue, 22 Oct 2002 13:07:00 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 1845Io-0002mR-00; Tue, 22 Oct 2002 21:06:58 +0100 Date: Tue, 22 Oct 2002 21:06:58 +0100 From: Christoph Hellwig To: Luben Tuikov Cc: Stephen Lord , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021022210658.A10581@infradead.org> References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.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: <3DB5AD3F.80402@splentec.com>; from luben@splentec.com on Tue, Oct 22, 2002 at 03:55:43PM -0400 X-archive-position: 1169 X-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 Tue, Oct 22, 2002 at 03:55:43PM -0400, Luben Tuikov wrote: > This is what wake_up_sync() does. wake_up() may reschedule > on an SMP system, since the other CPUs may be able to get > another task to run. This is why there are two different > implementations wake_up() and wake_up_sync(). > > If you have 4 CPUs, 3 idle and call wake_up() why should > the 3 idle CPUs _STAY_ idle, _until_ you (later) call schedule() > and _then_ to schedule another task on the idle CPUs, and > you to continue to go on, say if you were a SCHED_FIFO, or > SCHED_OTHER... > > BTW, that the _whole_ point of SMP -- _symmetric_ MP. Could you please give me some of thev crack you're smoking? I'd suggest you take an actual look at the implementation of wake_up/wake_up_sync. From owner-linux-xfs@oss.sgi.com Tue Oct 22 13:31:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 13:31:44 -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 g9MKVbuR031489 for ; Tue, 22 Oct 2002 13:31:38 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 1845gj-0002vV-00; Tue, 22 Oct 2002 21:31:41 +0100 Date: Tue, 22 Oct 2002 21:31:40 +0100 From: Christoph Hellwig To: Luben Tuikov Cc: linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021022213140.A11191@infradead.org> References: <3DB49424.9E4CAC0F@splentec.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: <3DB49424.9E4CAC0F@splentec.com>; from luben@splentec.com on Mon, Oct 21, 2002 at 07:56:20PM -0400 X-archive-position: 1170 X-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 Mon, Oct 21, 2002 at 07:56:20PM -0400, Luben Tuikov wrote: > Problem: on an SMP system, BANG#@!, the unthinkable happens. > Solution: never sleep when holding a lock. > > This patch applies to CVS code as of about 18:30 EDT > on Mon Oct 21 (today), and is self-explanatory. > > This patch fixes the problem of the mount going into D state > indefinitely when the RAID is syncing and mount is run > right after mkfs.xfs (from shell script, no sleep between, > low system load, SMP). Bug is real, fix is wrong. The right fix for this issue is to move the wake_up outside the lock, like below. I'll commit this patch together with a few related changes tmorrow when I'm back in the office. --- /usr/tmp/TmpDir.8821-0/linux/fs/xfs/pagebuf/page_buf.c_1.66 Tue Oct 22 16:29:54 2002 +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 22 23:44:25 2002 @@ -709,12 +709,8 @@ bh->b_next = pb_resv_bh; pb_resv_bh = bh; pb_resv_bh_cnt++; - - if (waitqueue_active(&pb_resv_bh_wait)) { - wake_up(&pb_resv_bh_wait); - } - spin_unlock_irqrestore(&pb_resv_bh_lock, flags); + wake_up(&pb_resv_bh_wait); } } From owner-linux-xfs@oss.sgi.com Tue Oct 22 14:06:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 14:06:42 -0700 (PDT) Received: from students.fct.unl.pt (students.fct.unl.pt [193.136.120.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ML6cuR001586 for ; Tue, 22 Oct 2002 14:06:39 -0700 Received: from localhost (pjsm@localhost) by students.fct.unl.pt (8.11.6/8.11.6) with ESMTP id g9ML6co03625; Tue, 22 Oct 2002 22:06:38 +0100 X-Authentication-Warning: students.fct.unl.pt: pjsm owned process doing -bs Date: Tue, 22 Oct 2002 22:06:38 +0100 (WEST) From: Paulo Matos To: linux-xfs@oss.sgi.com cc: Eric Sandeen Subject: Re: RH 8.0 installer In-Reply-To: <1035316705.551.40.camel@stout.americas.sgi.com> Message-ID: X-GPG-PUBLIC_KEY: http://students.fct.unl.pt/~pjsm/pjsm_fct.public.asc X-GPG-FINGRPRINT: 1024D/1DD3CA2F 5E95 9FD3 3435 A763 18E9 FB57 282B BCD7 1DD3 CA2F MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by students.fct.unl.pt id g9ML6co03625 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9ML6euR001587 X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pjsm@fct.unl.pt Precedence: bulk X-list: linux-xfs Hi all! Hi Russell! On 22 Oct 2002, Eric Sandeen wrote: sandeen> Yep, it's Russell Cattelan here at SGI, he originally posted the sandeen> message that the installer was released, along with all the sandeen> caveats. sandeen> sandeen> Feel free to just send bug reports (and patches...) to sandeen> the list, though. sandeen> sandeen> 1.2pre2 will be populated when it's available... Does 'pre2' refers to XFS or to the installer? Looking at .discinfo: 1031690066.345824 Psyche 8.0 i386 6 RedHat/base RedHat/RPMS RedHat/pixmaps i noticed that 'RedHat/pixmaps' does not exists on CD image... don't know if this matters or not... Are images/boot*.img XFS ready? I'm asking this because on previous releases I could never fit a XFS kernel on a normal 1.44M disk ;) I'll start testing this out ... (DISK/CD/FTP/HTTP + text/graphic/kickstart) -- Paulo Matos ----------------------------------- ---------------------------------- |Sys & Net Admin | Servi鏾 de Inform醫ica | |Faculdade de Ci阯cias e Tecnologia | Tel: +351-21-2948596 | |Universidade Nova de Lisboa | Fax: +351-21-2948548 | |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | ----------------------------------- ---------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 22 14:33:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 14:33:40 -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 g9MLXbuR003665 for ; Tue, 22 Oct 2002 14:33:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA57766; Tue, 22 Oct 2002 16:33: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 QAA81970; Tue, 22 Oct 2002 16:33:35 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9MLTsL14160; Tue, 22 Oct 2002 16:29:54 -0500 Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c From: Steve Lord To: Luben Tuikov Cc: linux-xfs In-Reply-To: <3DB5AD3F.80402@splentec.com> References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 22 Oct 2002 16:29:54 -0500 Message-Id: <1035322194.13625.70.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1172 X-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-22 at 14:55, Luben Tuikov wrote: > > No! > > This is what wake_up_sync() does. wake_up() may reschedule > on an SMP system, since the other CPUs may be able to get > another task to run. This is why there are two different > implementations wake_up() and wake_up_sync(). > > If you have 4 CPUs, 3 idle and call wake_up() why should > the 3 idle CPUs _STAY_ idle, _until_ you (later) call schedule() > and _then_ to schedule another task on the idle CPUs, and > you to continue to go on, say if you were a SCHED_FIFO, or > SCHED_OTHER... > > BTW, that the _whole_ point of SMP -- _symmetric_ MP. > > Bugs like this and the one recently found by Tom Wang > an me, are elementary OS 101 and Programming 101. Maybe a major > overhaul of the source should be done. > > Anyway, if you really DO THINK that you're right, maybe you should > INSIST that the code is LEFT as it was, with a call to wake_up(). > > -- > Luben > So tell me, what is ixfs? http://www.splentec.com/contacts.htm 'Asia: www.insightstor.com' http://www.insightstor.com/partnership.html * File System : We have developed independent file system, ixfs and support the development and compatibility with various File Systems. And lets keep the discussion technical, if you want to use our file system without a single line of credit and claim it as your own, then you might want to be more civil about it. 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 22 15:03:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 15:03:30 -0700 (PDT) Received: from [211.161.61.39] (sw59-151-201.adsl.seed.net.tw [61.59.151.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MM3CuR005692 for ; Tue, 22 Oct 2002 15:03:23 -0700 Received: from [211.161.26.39] by [211.161.75.39] with SMTP (MDaemon.v2.7.SP4.R) for ; Sun, 20 Oct 2002 11:28:24 +0800 From: 1bvccbngn30by@snb.ch To: w_22b5k12c15@sikorsky.com Subject: =?ISO-8859-1?Q?=B9q=B8=A3=B8=C9=B2=DF=AFZ=BD=D2=B5{=B3q=B3q=C5=DC=A6=A8=A5=FA=BA=D0=A4=F9?= Date: 20 Oct 2002 11:40:39 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; 琍戳, 01 る 2002 06:16:37 -0700 (EDT) Reply-To: receive_adm@topservice.net X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com X-Return-Path: 1bvccbngn30by@snb.ch X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: 1bvccbngn30by@snb.ch Precedence: bulk X-list: linux-xfs
PChome7-8-9る約,狦讽⊿Τǎ,瞷翴阑临ㄓ眔の
From owner-linux-xfs@oss.sgi.com Tue Oct 22 15:04:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 15:05:01 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MM4xuR005938 for ; Tue, 22 Oct 2002 15:04:59 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MM4Kf25149; Tue, 22 Oct 2002 18:04:20 -0400 Message-ID: <3DB5CB65.9F472279@splentec.com> Date: Tue, 22 Oct 2002 18:04:21 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Stephen Lord , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.com> <20021022210658.A10581@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Tue, Oct 22, 2002 at 03:55:43PM -0400, Luben Tuikov wrote: > > This is what wake_up_sync() does. wake_up() may reschedule > > on an SMP system, since the other CPUs may be able to get > > another task to run. This is why there are two different > > implementations wake_up() and wake_up_sync(). > > > > If you have 4 CPUs, 3 idle and call wake_up() why should > > the 3 idle CPUs _STAY_ idle, _until_ you (later) call schedule() > > and _then_ to schedule another task on the idle CPUs, and > > you to continue to go on, say if you were a SCHED_FIFO, or > > SCHED_OTHER... > > > > BTW, that the _whole_ point of SMP -- _symmetric_ MP. > > Could you please give me some of thev crack you're smoking? > > I'd suggest you take an actual look at the implementation > of wake_up/wake_up_sync. I have. -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 15:08:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 15:08:08 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MM85uR006985 for ; Tue, 22 Oct 2002 15:08:06 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MM7Xf25225; Tue, 22 Oct 2002 18:07:33 -0400 Message-ID: <3DB5CC26.D5F4BB84@splentec.com> Date: Tue, 22 Oct 2002 18:07:34 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Mon, Oct 21, 2002 at 07:56:20PM -0400, Luben Tuikov wrote: > > Problem: on an SMP system, BANG#@!, the unthinkable happens. > > Solution: never sleep when holding a lock. > > > > This patch applies to CVS code as of about 18:30 EDT > > on Mon Oct 21 (today), and is self-explanatory. > > > > This patch fixes the problem of the mount going into D state > > indefinitely when the RAID is syncing and mount is run > > right after mkfs.xfs (from shell script, no sleep between, > > low system load, SMP). > > Bug is real, fix is wrong. The right fix for this issue is to > move the wake_up outside the lock, like below. I'll commit > this patch together with a few related changes tmorrow when > I'm back in the office. IOW, wake_up_sync() was no good? Yes, you could move it out of the ipq lock, but wake_up_sync() would do. BTW, what is the purpose of wake_up_sync()? > --- /usr/tmp/TmpDir.8821-0/linux/fs/xfs/pagebuf/page_buf.c_1.66 Tue Oct 22 16:29:54 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 22 23:44:25 2002 > @@ -709,12 +709,8 @@ > bh->b_next = pb_resv_bh; > pb_resv_bh = bh; > pb_resv_bh_cnt++; > - > - if (waitqueue_active(&pb_resv_bh_wait)) { > - wake_up(&pb_resv_bh_wait); > - } > - > spin_unlock_irqrestore(&pb_resv_bh_lock, flags); > + wake_up(&pb_resv_bh_wait); > } > } > -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 15:14:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 15:14:39 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MMEbuR007753 for ; Tue, 22 Oct 2002 15:14:38 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MMEZf25356; Tue, 22 Oct 2002 18:14:35 -0400 Message-ID: <3DB5CDCC.A2A4C96C@splentec.com> Date: Tue, 22 Oct 2002 18:14:36 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs Subject: Re: PATCH: sleeping while holding a lockin _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.com> <1035322194.13625.70.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > So tell me, what is ixfs? > > http://www.splentec.com/contacts.htm > > 'Asia: www.insightstor.com' > > http://www.insightstor.com/partnership.html > > * File System : > We have developed independent file system, ixfs and support the > development and compatibility with various File Systems. I have absolutely no idea. Your guess is as good as mine. BTW, first time I see this. I'll ask my boss when I see him around. > And lets keep the discussion technical, Yes, let's keep it technical. > if you want to use our > file system without a single line of credit and claim it as your > own, then you might want to be more civil about it. No, I'd _personally_ never do such a thing. I have a very high moral sense to the point that it is not an advantage but a liability. (We _have_ to live in this world -- don't we?) Anyway, I'll investigate the issue raised above. -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 15:52:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 15:52:17 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MMqDuR010853 for ; Tue, 22 Oct 2002 15:52:15 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MMpbf25995; Tue, 22 Oct 2002 18:51:37 -0400 Message-ID: <3DB5D67A.26137CFC@splentec.com> Date: Tue, 22 Oct 2002 18:51:38 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Stephen Lord , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.com> <20021022210658.A10581@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Tue, Oct 22, 2002 at 03:55:43PM -0400, Luben Tuikov wrote: > > This is what wake_up_sync() does. wake_up() may reschedule > > on an SMP system, since the other CPUs may be able to get > > another task to run. This is why there are two different > > implementations wake_up() and wake_up_sync(). > > > > If you have 4 CPUs, 3 idle and call wake_up() why should > > the 3 idle CPUs _STAY_ idle, _until_ you (later) call schedule() > > and _then_ to schedule another task on the idle CPUs, and > > you to continue to go on, say if you were a SCHED_FIFO, or > > SCHED_OTHER... > > > > BTW, that the _whole_ point of SMP -- _symmetric_ MP. > > Could you please give me some of thev crack you're smoking? Yep, real professional! -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 16:55:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 16:55:40 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MNtauR015138 for ; Tue, 22 Oct 2002 16:55:37 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MNt0f27252; Tue, 22 Oct 2002 19:55:00 -0400 Message-ID: <3DB5E554.D4BD1485@splentec.com> Date: Tue, 22 Oct 2002 19:55:00 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Mon, Oct 21, 2002 at 07:56:20PM -0400, Luben Tuikov wrote: > > Problem: on an SMP system, BANG#@!, the unthinkable happens. > > Solution: never sleep when holding a lock. > > > > This patch applies to CVS code as of about 18:30 EDT > > on Mon Oct 21 (today), and is self-explanatory. > > > > This patch fixes the problem of the mount going into D state > > indefinitely when the RAID is syncing and mount is run > > right after mkfs.xfs (from shell script, no sleep between, > > low system load, SMP). > > Bug is real, fix is wrong. I think so too! BTW, shouldn't flags be unsigned long? (Rather than int?) Also, why is there 2 identical if() checks for pb_resv_bh_cnt? One inside the lock and one outside? Isn't this begging for a race condition? After the attidute I've seen here, I'd better put everything in question form, else woe is me. Now I'm not even sure in my own eyes... (I actually printed on paper the code in question before typing all this... Thanks a lot Christoph!) > The right fix for this issue is to > move the wake_up outside the lock, like below. I'll commit > this patch together with a few related changes tmorrow when > I'm back in the office. > > --- /usr/tmp/TmpDir.8821-0/linux/fs/xfs/pagebuf/page_buf.c_1.66 Tue Oct 22 16:29:54 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 22 23:44:25 2002 > @@ -709,12 +709,8 @@ > bh->b_next = pb_resv_bh; > pb_resv_bh = bh; > pb_resv_bh_cnt++; > - > - if (waitqueue_active(&pb_resv_bh_wait)) { > - wake_up(&pb_resv_bh_wait); > - } > - > spin_unlock_irqrestore(&pb_resv_bh_lock, flags); > + wake_up(&pb_resv_bh_wait); > } > } > -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 16:57:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 16:57:51 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MNvmuR015478 for ; Tue, 22 Oct 2002 16:57:49 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9MNvif27304; Tue, 22 Oct 2002 19:57:44 -0400 Message-ID: <3DB5E5F8.22AC8657@splentec.com> Date: Tue, 22 Oct 2002 19:57:44 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs Subject: Re: PATCH: sleeping while holding a lockin _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <1035289272.9684.13.camel@laptop.americas.sgi.com> <3DB5AD3F.80402@splentec.com> <1035322194.13625.70.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > > So tell me, what is ixfs? > > http://www.splentec.com/contacts.htm > > 'Asia: www.insightstor.com' > > http://www.insightstor.com/partnership.html > > * File System : > We have developed independent file system, ixfs and support the > development and compatibility with various File Systems. > Steve, I just learned that ``ixfs'' is filesystem for a ``jukebox/optical disk changer'', developed by another company. This is all I know. -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 17:20:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 17:20:17 -0700 (PDT) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N0KFuR017375 for ; Tue, 22 Oct 2002 17:20:15 -0700 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id RAA14026 for ; Tue, 22 Oct 2002 17:20:14 -0700 (PDT) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002102217213825504 ; Tue, 22 Oct 2002 17:21:38 -0700 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Oct 2002 17:20:15 -0700 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 22 Oct 2002 17:20:14 -0700 Message-ID: <3DB5EB3E.8A5C1D68@digeo.com> Date: Tue, 22 Oct 2002 17:20:14 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Luben Tuikov , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2002 00:20:14.0215 (UTC) FILETIME=[F4FB4170:01C27A29] X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > - > - if (waitqueue_active(&pb_resv_bh_wait)) { > - wake_up(&pb_resv_bh_wait); > - } > - > spin_unlock_irqrestore(&pb_resv_bh_lock, flags); > + wake_up(&pb_resv_bh_wait); > } > } > I'd be interested in a description of how this can help avoid a deadlock. From owner-linux-xfs@oss.sgi.com Tue Oct 22 18:21:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 18:21:52 -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 g9N1LnuR024345 for ; Tue, 22 Oct 2002 18:21:50 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA47598; Tue, 22 Oct 2002 20:21:49 -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 UAA05288; Tue, 22 Oct 2002 20:21:45 -0500 (CDT) Date: Tue, 22 Oct 2002 20:17:20 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Luben Tuikov cc: Christoph Hellwig , linux-xfs Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c In-Reply-To: <3DB5E554.D4BD1485@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1181 X-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, 22 Oct 2002, Luben Tuikov wrote: > Also, why is there 2 identical if() checks for pb_resv_bh_cnt? > One inside the lock and one outside? Isn't this begging for > a race condition? Actually, this was recently changed to be this way to -avoid- a race, as suggested by another third party (see TAKE message from a day or two ago...) It used to say (pseudo-code): if reserved bh pool seems full (not checking under spinlock) just free the bh else spin_lock the reserved pool lock add the bh back to the reserved pool wake up waiters spin_unlock the reserved pool lock but, in between checking whether the pool is full, and taking action, pool could actually have emptied or filled, so we could either free when it should be added to the pool, or vice versa. So now, we do: if reserved pool seems to not be full (spinlock not held) spin_lock the reserved pool lock check whether the reserved pool is -really- not full if it is really not full, add the bh back to the pool wake up waiters spin_unlock if the pool is probably full, or is definitely full, free the bh I guess this still could race in the case where the pool seems to be full when not under the spinlock, and we free it when we shouldn't... although I'd have to think what the implications of that might be. :) We really don't want to have to aquire a lock every time we free a buffer head here, this all only matters for a low-memory case. And, for all the attention this code has received in the past few days, it actually should rarely be executed in the "not full" case. > After the attidute I've seen here, I'd better put everything > in question form, else woe is me. Eh, just don't accuse the SGI fs gurus (which is a position to which I aspire, but do not claim to have attained) of failing C 101, and we'll all get along fine. ;-) The XFS code is vast and complex, and there are only a handful of people working on it for Linux, and development stretches back into time... and yes, there are bugs. If you find one, just report it, and send patches if you can. And if you are using XFS commercially, remember what you paid for it, and refrain from agitating the people who provide it to you. This is a pretty friendly place in general. -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:01:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:01:14 -0700 (PDT) Received: from nycsmtp2out.rdc-nyc.rr.com (nycsmtp2out.rdc-nyc.rr.com [24.29.99.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N31BuR031900 for ; Tue, 22 Oct 2002 20:01:12 -0700 Received: from si.rr.com (24-90-17-59.si.rr.com [24.90.17.59]) by nycsmtp2out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g9N2vtlY005176; Tue, 22 Oct 2002 22:57:55 -0400 (EDT) Message-ID: <3DB61153.3010509@si.rr.com> Date: Tue, 22 Oct 2002 23:02:43 -0400 From: Frank Davis Reply-To: fdavis@si.rr.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lord@sgi.com CC: linux-xfs@oss.sgi.com Subject: XFS removal of #define STATIC static Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fdavis@si.rr.com Precedence: bulk X-list: linux-xfs Hello all, Per a recent email on linux-kernel@vger.kernel.org, Alan Cox stated that #define STATIC static is outdated (no longer used). As a result, I've removed references to the outdated macro in all files except for XFS (defined in fs/xfs/linux/xfs_linux.h) within the 2.5.44-ac1 kernel. Would it be possible for the XFS team to also remove this outdated macro? Thanks. Regards, Frank From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:13:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:13:47 -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 g9N3DiuR000784 for ; Tue, 22 Oct 2002 20:13:44 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA50176; Tue, 22 Oct 2002 22:13:44 -0500 (CDT) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-39.corp.sgi.com [134.15.64.39]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id WAA31266; Tue, 22 Oct 2002 22:13:42 -0500 (CDT) Subject: Re: XFS removal of #define STATIC static From: Stephen Lord To: fdavis@si.rr.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DB61153.3010509@si.rr.com> References: <3DB61153.3010509@si.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 22 Oct 2002 22:09:28 -0500 Message-Id: <1035342569.1086.39.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1183 X-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-22 at 22:02, Frank Davis wrote: > Hello all, > Per a recent email on linux-kernel@vger.kernel.org, Alan Cox stated > that > #define STATIC static > > is outdated (no longer used). As a result, I've removed references to > the outdated macro in all files except for XFS (defined in > fs/xfs/linux/xfs_linux.h) within the 2.5.44-ac1 kernel. Would it be > possible for the XFS team to also remove this outdated macro? Thanks. You mean you could not face all 833 of them which are in there ;-) I can think of better ways to spend an afternoon I have to admit. The only reason I can think of needing this is for symbol tables in debuggers - and trying to keep some semblance of the same code base between Irix and Linux. Not sure if we really have a debugger setup on linux where being able to turn off static helps to be honest, does a gdb symbol table include static functions? Unless someone is feeling bored and wants to knock up a sed script I am not sure this will happen, but I don't really have an objection beyond the above. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:15:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:15:21 -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 g9N3FIuR001068 for ; Tue, 22 Oct 2002 20:15:18 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B7C5F142A2; Wed, 23 Oct 2002 05:15:18 +0200 (MEST) Date: Wed, 23 Oct 2002 05:15:17 +0200 From: Andi Kleen To: Christoph Hellwig Cc: Luben Tuikov , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021023051517.A17128@wotan.suse.de> References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021022213140.A11191@infradead.org> User-Agent: Mutt/1.3.22.1i X-archive-position: 1184 X-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 Tue, Oct 22, 2002 at 09:31:40PM +0100, Christoph Hellwig wrote: > Bug is real, fix is wrong. The right fix for this issue is to > move the wake_up outside the lock, like below. I'll commit > this patch together with a few related changes tmorrow when > I'm back in the office. Are you sure? IMHO neither wake_up() nor wake_up_sync() should sleep. And they don't in neither O(1) nor the old scheduler. Also there are no lock ordering issues I can see. So in theory it should be fine to call wake_up() with the lock held. In fact I think you even need the lock to avoid lost wakeups. -Andi > From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:16:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:16:36 -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 g9N3GYuR001496 for ; Tue, 22 Oct 2002 20:16:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA60315 for ; Tue, 22 Oct 2002 22:16:33 -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 WAA50431 for ; Tue, 22 Oct 2002 22:16:33 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9N3C8q07715; Tue, 22 Oct 2002 22:12:08 -0500 Message-Id: <200210230312.g9N3C8q07715@stout.americas.sgi.com> Date: Tue, 22 Oct 2002 22:12:08 -0500 Subject: TAKE - pagebuf flags cleanup X-archive-position: 1185 X-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 pagebuf flags cleanup Date: Tue Oct 22 20:15:25 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:130823a linux/fs/xfs/pagebuf/page_buf.c - 1.69 linux/fs/xfs/pagebuf/page_buf.h - 1.44 - Remove comment references to dead pagebuf flags Consistently use page_buf_flags_t for flag vars From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:17:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:17:15 -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 g9N3HCuR001873 for ; Tue, 22 Oct 2002 20:17:13 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 779F0142A2; Wed, 23 Oct 2002 05:17:13 +0200 (MEST) Date: Wed, 23 Oct 2002 05:17:13 +0200 From: Andi Kleen To: Luben Tuikov Cc: Christoph Hellwig , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021023051713.B17128@wotan.suse.de> References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB5CC26.D5F4BB84@splentec.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1186 X-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 > BTW, what is the purpose of wake_up_sync()? wake_up_sync() only wakes up the first process/thread waiting on the wait queue. Not all. This is to avoid the 'thundering herd' lock performance problem with many waiters when lots of processes get woken up all the time just to discover that there is no work for them yet and go to sleep again. But it needs careful auditing of the code if it can really tolerate wake one. -Andi > From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:23:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:23:28 -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 g9N3NPuR003040 for ; Tue, 22 Oct 2002 20:23:26 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 6C88114327; Wed, 23 Oct 2002 05:22:16 +0200 (MEST) Date: Wed, 23 Oct 2002 05:22:15 +0200 From: Andi Kleen To: Stephen Lord Cc: fdavis@si.rr.com, linux-xfs@oss.sgi.com Subject: Re: XFS removal of #define STATIC static Message-ID: <20021023052215.A18994@wotan.suse.de> References: <3DB61153.3010509@si.rr.com> <1035342569.1086.39.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1035342569.1086.39.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1187 X-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 > The only reason I can think of needing this is for symbol tables > in debuggers - and trying to keep some semblance of the same > code base between Irix and Linux. Not sure if we really have > a debugger setup on linux where being able to turn off static > helps to be honest, does a gdb symbol table include static > functions? It used to help with old kdb (which didn't know about static functions). But since CONFIG_KALLSYMS was implemented this is obsolete. gdb should always know about static functions too. -Andi From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:39:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:40:01 -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 g9N3dwuR004983 for ; Tue, 22 Oct 2002 20:39:58 -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 UAA08895 for ; Tue, 22 Oct 2002 20:40:03 -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 NAA13757 for linux-xfs@oss.sgi.com; Wed, 23 Oct 2002 13:38:46 +1000 (EST) Date: Wed, 23 Oct 2002 13:38:46 +1000 (EST) From: Nathan Scott Message-Id: <200210230338.NAA13757@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor portability change X-archive-position: 1188 X-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 More for consistency than anything else... Date: Tue Oct 22 20:34:30 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:130824a linux/fs/xfs/xfs_vfsops.c - 1.392 linux/fs/xfs/xfs_iget.c - 1.176 linux/fs/xfs/xfs_mount.c - 1.306 linux/fs/xfs/linux/xfs_super.h - 1.31 linux/fs/xfs/linux/xfs_super.c - 1.221 - Move a couple of routines with knowledge of pagebuf target, struct block device, and struct inode with the rest of the Linux-specific code. From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:42:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:43:01 -0700 (PDT) Received: from oss.sgi.com (cs9345-181.austin.rr.com [24.93.45.181]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3gtuR005554 for ; Tue, 22 Oct 2002 20:42:56 -0700 Message-Id: <200210230342.g9N3gtuR005554@oss.sgi.com> From: "Money" Date: Tue, 22 Oct 2002 22:23:51 To: linux-xfs@oss.sgi.com Subject: Your Approved MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: explosive_growth@hotmail.com Precedence: bulk X-list: linux-xfs SEND EMAIL $$$ MAKE BIG MONEY Earn THOUSAND US$ in Multi-Level Email Reports ! Dear Future Millionaire ! I'll make you a promise. READ THIS TO THE END ! Follow what it says to the letter - and you will NEVER worry whether a RECESSION is coming or not, who is your Country's President, or whether you keep your current job or not. Yes, I know what you are thinking. I never responded to one of these before either ! One day though, something just said "you throw away $25.00 going to a movie for 2 hours". "What the heck." Believe me, no matter where you believe "those feelings" come from, I thank goodness every day that I had that feeling. I cannot imagine where I would be or what I would be doing had I not. Read on. It's TRUE. Every word of it ! It is LEGAL as in the truest sense of the word ! Simply because you are buying something of value ! ************************************************** AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from the comfort of your home ! THANKS TO THE COMPUTER AGE AND THE INTERNET! BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR! Before you say, "Bull", please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there is "absolutely NO Laws prohibiting the participation in the program, and if people can follow the simple instruction, " they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER ! *************************************************** This is what one had to say: "Thanks to this profitable opportunity". I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received a total $610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. *************************************************** Another said: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa.3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that,I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything." More testimonials later but first: =====PRINT THIS NOW FOR YOUR FUTURE REFERENCE===== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following匱HEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: ===Order all 5 reports shown on the list below=== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mailing problems. WHEN YOU PLACE YOUR ORDER, MAKE SURE YOU ORDER EACH OF THE 5 REPORTS. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00 Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also, make a floppy of these reports and keep it on your desk in case something happens to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step "1 through 6". Or you will lose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter it, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all themoney. But it doesn't work this way. Believe us, some have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, HONESTY reaps the REWARDS!!! This IS a legitimate BUSINESS powered by the present Information Technology we call the INTERNET, the INCOME generating capacity of MULTI-LEVEL-MARKETING,and the effectiveness of DIRECT MAIL ORDER System ! The name of this program is MULTI-LEVEL EMAIL REPORTS,And Our Products are " How To " Informations ! YOU ARE ACTUALLY RUNNING AN INFORMATION SERVICES BUSINESS ! You are offering these products for sale and getting paid for it. Treat it as such and you will be VERY PROFITABLE in a SHORT period of TIME ! 1. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting his fortunes. 2. Move the name & address in REPORT #4 down to REPORT #5. 3. Move the name & address in REPORT #3 down to REPORT #4. 4. Move the name & address in REPORT #2 down to REPORT #3. 5. Move the name & address in REPORT #1 down to REPORT #2. 6. Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! This is critical to YOUR success ! ************************************************* Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you lose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD#1: BY SENDING BULK E-MAIL LEGALLY ======================================== Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% (2/10 of 1%) response (the response could be much better but lets just say it is only 0.2%). Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for Report #1. Those 10 people responded by sending out 5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report #2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is1000 orders for Report #3. Those 1000 people send 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response is 10,000 orders for Report #4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report #5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars) ! Your total income in this example is: 1. $50+2.. $500+3.. $5,000+4.. $50,000+5. $500,000. Grand total $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! *************************************************** REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting, with thousands more coming on line every day. Believe me, many people will do just that and more! METHOD #2: BY PLACING FREE ADS ON THE INTERNET ============================================== Advertising on the net is very, very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method #1 and add Method #2 as you go along. For every $5 you receive, all you must do is e-mail the Report to the recipient immediately as possible. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they cannot advertise until they receive the report. ************************************************ AVAILABLE REPORTS The reason for the "CASH" is not because this is illegal or somehow "wrong". It is simply about TIME. Time for checks or credit cards to be cleared or approved, etc. Concealing it simply so no one can SEE if there is money in the envelope and steal it before it gets to you. ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. In one of those sheets of paper write the NUMBER & NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and YOUR NAME and Postal Address. ************************************************ PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1: The Insider's Guide to Advertising for Free On The Net Order Report #1 from: Quinn Tiemann 1801 Warner Ranch Road #235 Round Rock, TX 78664 REPORT #2: The Insider's Guide to Sending Bulk -Email on the Net Order Report #2 from: Julie Hellman 2705 Harrowden Drive Austin, TX 78727 REPORT #3: Secret to Multilevel Marketing On The Net Order Report #3 from: Eldon Hufford P.O. Box 13010 Mesa, AZ 85216 REPORT #4: How To Become Millionaire Using MLM & The Net Order Report #4 from: Jsajm Marie Quino PO Box 292 MCPO Subangdaku Mandaue City 6014 Cebu - Philippines REPORT #5: How To Send Out One Million Emails for Free Order Report #5 From: Denise Wyka 13719 Ironwood Circle Lockport, IL 60441 _________________________________________________ $$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at lest 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed on a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME, SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! FOLLOWING IS A NOTE FROM THE ORGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your NAME and ADDRESS in Report #1, and moved others to #2..#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out emails, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. If you have any questions of the legality of this program contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, and Washington, D.C. ===============MORE TESTIMONIALS================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving "junk mail". I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she received total $147,200.00.all CASH! I was shocked. I have joined Jody in her "hobby". Mitchell Wolf C.P.A., Chicago, Illinois ************************************************* "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative as I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back"."I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 CASH in the first 12 weeks !The nice thing about this deal is that it does not matter where people live. There simply isn't abetter investment with a faster return and so big". Dan Sondstrum Alberta, CA Send E-Mail to: shellyk1965@msn.com Click Here to to excluded from future mailings. If the above link is unavailable send a blank email to takemeoff@yourpossiblesolution.com with "stop" in the subject line If both of the above methods do not work you may call 1-888-644-7618 to be taken off our list. From owner-linux-xfs@oss.sgi.com Tue Oct 22 20:57:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 20:57: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 g9N3vYuR007934 for ; Tue, 22 Oct 2002 20:57:34 -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 UAA04028 for ; Tue, 22 Oct 2002 20:57:39 -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 NAA27022; Wed, 23 Oct 2002 13:56:23 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id BC264300B29; Wed, 23 Oct 2002 13:56:22 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 8286713B5A; Wed, 23 Oct 2002 13:56:22 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: fdavis@si.rr.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS removal of #define STATIC static In-reply-to: Your message of "22 Oct 2002 22:09:28 EST." <1035342569.1086.39.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Oct 2002 13:56:17 +1000 Message-ID: <19694.1035345377@kao2.melbourne.sgi.com> X-archive-position: 1190 X-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 22 Oct 2002 22:09:28 -0500, Stephen Lord wrote: >On Tue, 2002-10-22 at 22:02, Frank Davis wrote: >> Hello all, >> Per a recent email on linux-kernel@vger.kernel.org, Alan Cox stated >> that >> #define STATIC static >> >> is outdated (no longer used). As a result, I've removed references to >> the outdated macro in all files except for XFS (defined in >> fs/xfs/linux/xfs_linux.h) within the 2.5.44-ac1 kernel. Would it be >> possible for the XFS team to also remove this outdated macro? Thanks. > >The only reason I can think of needing this is for symbol tables >in debuggers - and trying to keep some semblance of the same >code base between Irix and Linux. Not sure if we really have >a debugger setup on linux where being able to turn off static >helps to be honest, does a gdb symbol table include static >functions? kdb has no problems with static functions. gdb has static functions in its symbol tables, but debugging (or disassembling) static inline functions with gdb is unreliable. There have been a few times when I have compiled with -DSTATIC= to get a decent disassembly under gdb. OTOH, it is just as easy to manually remove static from the individual function you are looking at. >Unless someone is feeling bored and wants to knock up a sed script >I am not sure this will happen, but I don't really have an objection >beyond the above. p_modify $(fgrep -rwl STATIC fs/xfs/) perl -i -lpe 's/\bSTATIC\b/static/g;' $(fgrep -rwl STATIC fs/xfs/) Hand edit fs/xfs/pagebuf/{page_buf_internal.h,xfs_linux.h}, fs/xfs/Makefile, fs/xfs/linux/Makefile, fs/xfs/pagebuf/Makefile Done. From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:03:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:03: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 g9N43ZuR009084 for ; Tue, 22 Oct 2002 21:03:35 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) 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 VAA02330 for ; Tue, 22 Oct 2002 21:03:40 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g9N43Ys12639; Wed, 23 Oct 2002 14:03:34 +1000 Date: Wed, 23 Oct 2002 14:03:34 +1000 From: Keith Owens Message-Id: <200210230403.g9N43Ys12639@sherman.melbourne.sgi.com> Subject: TAKE - Replace STATIC with static in xfs code X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs The use of STATIC to switch between static and extern is deprecated. Change STATIC to static in source, remove -DSTATIC from Makefiles, remove #define of STATIC. Date: Tue Oct 22 20:54:05 PDT 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:130826a linux/fs/xfs/xfs_trans_dquot.c - 1.38 linux/fs/xfs/xfs_log.c - 1.258 linux/fs/xfs/xfs_ialloc.c - 1.160 linux/fs/xfs/xfs_extfree_item.c - 1.51 linux/fs/xfs/xfs_buf_item.c - 1.130 linux/fs/xfs/xfs_trans_inode.c - 1.40 linux/fs/xfs/xfs_da_btree.c - 1.136 linux/fs/xfs/xfs_trans_ail.c - 1.65 linux/fs/xfs/xfs_vnodeops.c - 1.569 linux/fs/xfs/xfs_dir.c - 1.145 linux/fs/xfs/xfs_rtalloc.c - 1.82 linux/fs/xfs/xfs_ialloc_btree.c - 1.69 linux/fs/xfs/xfs_dmapi.c - 1.82 linux/fs/xfs/xfs_inode_item.c - 1.106 linux/fs/xfs/Makefile - 1.150 linux/fs/xfs/xfs_qm_syscalls.c - 1.70 linux/fs/xfs/xfs_log_recover.c - 1.248 linux/fs/xfs/xfs_trans_item.c - 1.33 linux/fs/xfs/xfs_dquot_item.c - 1.31 linux/fs/xfs/xfs_vfsops.c - 1.393 linux/fs/xfs/xfs_iget.c - 1.177 linux/fs/xfs/xfs_bmap_btree.c - 1.130 linux/fs/xfs/xfs_dquot.c - 1.71 linux/fs/xfs/xfs_dir_leaf.c - 1.106 linux/fs/xfs/xfs_mount.c - 1.307 linux/fs/xfs/xfs_btree.c - 1.101 linux/fs/xfs/xfs_qm.c - 1.89 linux/fs/xfs/xfs_inode.c - 1.357 linux/fs/xfs/xfs_attr_leaf.c - 1.65 linux/fs/xfs/xfs_trans.c - 1.136 linux/fs/xfs/xfs_alloc.c - 1.160 linux/fs/xfs/xfs_bmap.c - 1.295 linux/fs/xfs/xfs_alloc_btree.c - 1.74 linux/fs/xfs/xfs_trans_buf.c - 1.106 linux/fs/xfs/xfs_rename.c - 1.42 linux/fs/xfs/xfs_attr.c - 1.99 linux/fs/xfs/linux/xfs_lrw.c - 1.173 linux/fs/xfs/linux/xfs_linux.h - 1.89 linux/fs/xfs/linux/Makefile - 1.64 linux/fs/xfs/linux/xfs_file.c - 1.78 linux/fs/xfs/linux/xfs_vnode.c - 1.101 linux/fs/xfs/linux/xfs_super.c - 1.222 linux/fs/xfs/linux/xfs_iops.c - 1.179 linux/fs/xfs/linux/xfs_ioctl.c - 1.79 linux/fs/xfs/xfs_acl.c - 1.35 linux/fs/xfs/linux/xfs_sysctl.c - 1.10 linux/fs/xfs/pagebuf/Makefile - 1.15 linux/fs/xfs/pagebuf/page_buf.c - 1.70 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.16 linux/fs/xfs/xfs_cap.c - 1.6 linux/fs/xfs/linux/xfs_aops.c - 1.9 From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:08:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:08:40 -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 g9N48cuR010181 for ; Tue, 22 Oct 2002 21:08:38 -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 VAA05693 for ; Tue, 22 Oct 2002 21:08:43 -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 OAA27191; Wed, 23 Oct 2002 14:07:26 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA38426; Wed, 23 Oct 2002 14:07:25 +1000 (EST) Date: Wed, 23 Oct 2002 14:07:25 +1000 From: Nathan Scott To: Keith Owens , Steve Lord Cc: fdavis@si.rr.com, linux-xfs@oss.sgi.com Subject: Re: XFS removal of #define STATIC static Message-ID: <20021023140724.A339620@wobbly.melbourne.sgi.com> References: <1035342569.1086.39.camel@laptop.americas.sgi.com> <19694.1035345377@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: <19694.1035345377@kao2.melbourne.sgi.com>; from kaos@sgi.com on Wed, Oct 23, 2002 at 01:56:17PM +1000 X-archive-position: 1192 X-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 Wed, Oct 23, 2002 at 01:56:17PM +1000, Keith Owens wrote: > On 22 Oct 2002 22:09:28 -0500, > Stephen Lord wrote: > >On Tue, 2002-10-22 at 22:02, Frank Davis wrote: > >> Hello all, > >> Per a recent email on linux-kernel@vger.kernel.org, Alan Cox stated > >> that > >> #define STATIC static > >> libxfs shares alot of this code, and it has different scoping requirements to the kernel for a number of functions (& hence is built with STATIC=). Please do not remove the use of STATIC here, there is no reason to do so & it will just make my life difficult maintaining that code. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:16:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:16:19 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N4GGuR011464 for ; Tue, 22 Oct 2002 21:16:17 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9N4FZf31778; Wed, 23 Oct 2002 00:15:35 -0400 Message-ID: <3DB62268.79A724BC@splentec.com> Date: Wed, 23 Oct 2002 00:15:36 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Christoph Hellwig , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> <20021023051713.B17128@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Andi Kleen wrote: > > > BTW, what is the purpose of wake_up_sync()? > > wake_up_sync() only wakes up the first process/thread waiting on the > wait queue. Not all. This is to avoid the 'thundering herd' lock performance > problem with many waiters when lots of processes get woken up all the time > just to discover that there is no work for them yet and go to sleep again. > But it needs careful auditing of the code if it can really tolerate > wake one. This was a rhetorical question... From what I can see and read, wake_up() and wake_up_sync() both wake up all non-exclusive sleepers and one exclusive sleeper. The NON _sync versions, OTOH, will call reschedule_idle(), which _may_ cause (if the conditions are favourable) _another_ task to run on _another_ CPU (SMP), _before_ the wake_up() returns. This will cause a problem if that other task does IO on xfs and the code is as it was several days ago. -- Luben P.S. This is more or less what had I explained when I was accused of smoking... From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:18:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:18:52 -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 g9N4IouR012069 for ; Tue, 22 Oct 2002 21:18:50 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 20B7514618; Wed, 23 Oct 2002 06:18:51 +0200 (MEST) Date: Wed, 23 Oct 2002 06:18:50 +0200 From: Andi Kleen To: Luben Tuikov Cc: Andi Kleen , Christoph Hellwig , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021023061850.A29006@wotan.suse.de> References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> <20021023051713.B17128@wotan.suse.de> <3DB62268.79A724BC@splentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB62268.79A724BC@splentec.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1194 X-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 > >From what I can see and read, wake_up() and wake_up_sync() both wake > up all non-exclusive sleepers and one exclusive sleeper. > > The NON _sync versions, OTOH, will call reschedule_idle(), which _may_ > cause (if the conditions are favourable) _another_ task to run > on _another_ CPU (SMP), _before_ the wake_up() returns. Yes of course. But other CPUs are completely independent anyways, so there can be tasks scheduled there any time, no matter if you call wake_up or not. > This will cause a problem if that other task does IO on xfs > and the code is as it was several days ago. Can you explain how exactly that leads to problems ? -Andi From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:23:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:23: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 g9N4NsuR012771 for ; Tue, 22 Oct 2002 21:23:54 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) 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 VAA04406 for ; Tue, 22 Oct 2002 21:23:59 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g9N4Nnd13275; Wed, 23 Oct 2002 14:23:49 +1000 Date: Wed, 23 Oct 2002 14:23:49 +1000 From: Keith Owens Message-Id: <200210230423.g9N4Nnd13275@sherman.melbourne.sgi.com> Subject: TAKE - Revert STATIC->static change X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Nathan Scott has pointed out that the XFS kernel code is also used to build libxfs for user space. The kernel and user space have different scoping rules, the STATIC macro is required for coexistence. That change did not last long, did it :) Date: Tue Oct 22 21:21:07 PDT 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs Undoes mod: 2.4.x-xfs:slinx:130826a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:130828a linux/fs/xfs/xfs_trans_dquot.c - 1.39 linux/fs/xfs/xfs_log.c - 1.259 linux/fs/xfs/xfs_ialloc.c - 1.161 linux/fs/xfs/xfs_extfree_item.c - 1.52 linux/fs/xfs/xfs_buf_item.c - 1.131 linux/fs/xfs/xfs_trans_inode.c - 1.41 linux/fs/xfs/xfs_da_btree.c - 1.137 linux/fs/xfs/xfs_trans_ail.c - 1.66 linux/fs/xfs/xfs_vnodeops.c - 1.570 linux/fs/xfs/xfs_dir.c - 1.146 linux/fs/xfs/xfs_rtalloc.c - 1.83 linux/fs/xfs/xfs_ialloc_btree.c - 1.70 linux/fs/xfs/xfs_dmapi.c - 1.83 linux/fs/xfs/xfs_inode_item.c - 1.107 linux/fs/xfs/Makefile - 1.151 linux/fs/xfs/xfs_qm_syscalls.c - 1.71 linux/fs/xfs/xfs_log_recover.c - 1.249 linux/fs/xfs/xfs_trans_item.c - 1.34 linux/fs/xfs/xfs_dquot_item.c - 1.32 linux/fs/xfs/xfs_vfsops.c - 1.394 linux/fs/xfs/xfs_iget.c - 1.178 linux/fs/xfs/xfs_bmap_btree.c - 1.131 linux/fs/xfs/xfs_dquot.c - 1.72 linux/fs/xfs/xfs_dir_leaf.c - 1.107 linux/fs/xfs/xfs_mount.c - 1.308 linux/fs/xfs/xfs_btree.c - 1.102 linux/fs/xfs/xfs_qm.c - 1.90 linux/fs/xfs/xfs_inode.c - 1.358 linux/fs/xfs/xfs_attr_leaf.c - 1.66 linux/fs/xfs/xfs_trans.c - 1.137 linux/fs/xfs/xfs_alloc.c - 1.161 linux/fs/xfs/xfs_bmap.c - 1.296 linux/fs/xfs/xfs_alloc_btree.c - 1.75 linux/fs/xfs/xfs_trans_buf.c - 1.107 linux/fs/xfs/xfs_rename.c - 1.43 linux/fs/xfs/xfs_attr.c - 1.100 linux/fs/xfs/linux/xfs_lrw.c - 1.174 linux/fs/xfs/linux/xfs_linux.h - 1.90 linux/fs/xfs/linux/Makefile - 1.65 linux/fs/xfs/linux/xfs_file.c - 1.79 linux/fs/xfs/linux/xfs_vnode.c - 1.102 linux/fs/xfs/linux/xfs_super.c - 1.223 linux/fs/xfs/linux/xfs_iops.c - 1.180 linux/fs/xfs/linux/xfs_ioctl.c - 1.80 linux/fs/xfs/xfs_acl.c - 1.36 linux/fs/xfs/linux/xfs_sysctl.c - 1.11 linux/fs/xfs/pagebuf/Makefile - 1.16 linux/fs/xfs/pagebuf/page_buf.c - 1.71 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.17 linux/fs/xfs/xfs_cap.c - 1.7 linux/fs/xfs/linux/xfs_aops.c - 1.10 From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:43:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:43:42 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N4heuR014219 for ; Tue, 22 Oct 2002 21:43:40 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9N4h7f32290; Wed, 23 Oct 2002 00:43:07 -0400 Message-ID: <3DB628DC.46897E95@splentec.com> Date: Wed, 23 Oct 2002 00:43:08 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Christoph Hellwig , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> <20021023051713.B17128@wotan.suse.de> <3DB62268.79A724BC@splentec.com> <20021023061850.A29006@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Andi Kleen wrote: > > > >From what I can see and read, wake_up() and wake_up_sync() both wake > > up all non-exclusive sleepers and one exclusive sleeper. > > > > The NON _sync versions, OTOH, will call reschedule_idle(), which _may_ > > cause (if the conditions are favourable) _another_ task to run > > on _another_ CPU (SMP), _before_ the wake_up() returns. > > Yes of course. But other CPUs are completely independent anyways, so > there can be tasks scheduled there any time, no matter if you call > wake_up or not. > > > This will cause a problem if that other task does IO on xfs > > and the code is as it was several days ago. > > Can you explain how exactly that leads to problems ? Hmm, ``exactly'' -- I wish! But shortly, a lock up. I've only been looking at the code for 2 days, but a number of things have caught my eye. First, we were getting BUG in unlock_page(), see xfs-bugzilla bug #182. Reducing the md page size to 4, made the problem to seemingly go away. Now we get mount in D state, when mounting a synced md array through lvm, and sometimes the other way around, when md is syncing... sleeping in pagebuf_iowait() indefinitely... I really wish I could explain ``exactly'' how this leads to problems, but for now I'm debugging. Andy, you must admit that there are bugs! And given the BUG()s we've been getting, they are somehow related to pb_*. If I could explain ``exactly'' how, the bugs would be fixed and we wouldn't be having this conversation. Anyway, for now any lead is a good lead. -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:43:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:43:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9N4hluR014318 for ; Tue, 22 Oct 2002 21:43:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9N4hls2014316 for linux-xfs@oss.sgi.com; Tue, 22 Oct 2002 21:43:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9N4hiuV014271 for ; Tue, 22 Oct 2002 21:43:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9N4HRER011699; Tue, 22 Oct 2002 21:17:27 -0700 Date: Tue, 22 Oct 2002 21:17:27 -0700 Message-Id: <200210230417.g9N4HRER011699@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 ------- Additional Comments From sandeen@sgi.com 2002-10-22 21:17 ------- Created an attachment (id=41) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=41&action=view) proposed patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 22 21:43:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Oct 2002 21:43:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9N4hluR014317 for ; Tue, 22 Oct 2002 21:43:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9N4hlbg014315 for linux-xfs@oss.sgi.com; Tue, 22 Oct 2002 21:43:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9N4hiuX014271 for ; Tue, 22 Oct 2002 21:43:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9N4Kaqp012502; Tue, 22 Oct 2002 21:20:36 -0700 Date: Tue, 22 Oct 2002 21:20:36 -0700 Message-Id: <200210230420.g9N4Kaqp012502@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 ------- Additional Comments From sandeen@sgi.com 2002-10-22 21:20 ------- Ok, here's what's going on. Erik had some files with "left-over" preallocation on the files, probably the result of some crash or other. (xfs pre-allocates space, but normally removes it when the file is closed). So, xfs was trying to clean up this pre-allocated space when the file in the snapshot was closed, but it was a read-only device, the I/O failed, and xfs shut down. The attached patch checks the VFS_RDONLY patch before calling xfs_inactive_free_eofblocks, and doesn't do it if the flag is present. This has the effect of leaving these blocks past EOF, but that's better than a shutdown, and it can be cleaned up when the fs is mounted read-write again. This also toggles the VFS_RDONLY flag -off- before doing recovery on a read-only mount, so that recovery can still do what it needs to do, as long as the underlying device is not read-only. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 23 04:00:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 04:00:26 -0700 (PDT) Received: from pc-1. ([202.108.68.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NB08uT012920 for ; Wed, 23 Oct 2002 04:00:16 -0700 x-esmtp: 0 0 1 Message-ID: <2492094-220021032363923502@sdjw-nt4.dic-sd.gov.cn> To: "NEW020913-20000-300000" <911@1234.com> From: "索文翻译公司" Subject: =?ISO-8859-1?Q?=CB=F7=CE=C4=B7=AD=D2=EB=D3=D0=CF=DE=B9=AB=CB=BE=A3=AC=B1=CA=D2=EB=A1=A2=BF=DA=D2=EB=A1=A2=CD=F8=D5=BE=B1=BE=B5=D8=BB=AF--www.soven.com?= Date: Wed, 23 Oct 2002 14:39:23 +0800 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 38 X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: faxin@21cn.com Precedence: bulk X-list: linux-xfs [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Oct 23 07:05:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 07:05:43 -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 g9NE5duR027353 for ; Wed, 23 Oct 2002 07:05:40 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA23405 for ; Wed, 23 Oct 2002 09:05:41 -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 JAA04770 for ; Wed, 23 Oct 2002 09:05:41 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9NE1Cq10406; Wed, 23 Oct 2002 09:01:12 -0500 Message-Id: <200210231401.g9NE1Cq10406@stout.americas.sgi.com> Date: Wed, 23 Oct 2002 09:01:12 -0500 Subject: TAKE - Fix root exec access checks on files with acls X-archive-position: 1200 X-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 Fix root exec access checks on files with acls The standard VFS access checks look for at least one +x bit set before allowing root (CAP_DAC_OVERRIDE) exec access to the file. This does the analogous thing for files with acls, looking for at least 1 effective +x ace on the file before granting root/CAP_DAC_OVERRIDE exec access. There has been some discussion on the acl-devel list that -any- +x on -any- ace (even only the mask) should allow exec access for root, but I think this method (checking for effective +x) makes more sense. Easy enough to change if the consensus shifts. This should close internal bug 870306, although I forgot to tell ptools that. :) Date: Wed Oct 23 07:00:12 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:130837a linux/fs/xfs/xfs_acl.c - 1.37 - When checking for CAP_DAC_OVERRIDE exec access on files with acls, look for an effective exec permission in the acls before granting access. From owner-linux-xfs@oss.sgi.com Wed Oct 23 07:52:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 07:52:20 -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 g9NEqHuR000969 for ; Wed, 23 Oct 2002 07:52:18 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184Mrs-0002wJ-00; Wed, 23 Oct 2002 15:52:20 +0100 Date: Wed, 23 Oct 2002 15:52:20 +0100 From: Christoph Hellwig To: Andi Kleen Cc: Luben Tuikov , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021023155220.A11192@infradead.org> References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> <20021023051713.B17128@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021023051713.B17128@wotan.suse.de>; from ak@suse.de on Wed, Oct 23, 2002 at 05:17:13AM +0200 X-archive-position: 1201 X-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 23, 2002 at 05:17:13AM +0200, Andi Kleen wrote: > > BTW, what is the purpose of wake_up_sync()? > > wake_up_sync() only wakes up the first process/thread waiting on the > wait queue. Not all. This is to avoid the 'thundering herd' lock performance > problem with many waiters when lots of processes get woken up all the time > just to discover that there is no work for them yet and go to sleep again. > But it needs careful auditing of the code if it can really tolerate > wake one. wake_up_sync() is exactly like wake_up() - just that it will never reschedule to woken up thread. Both wake_up() and wake_up_sync() never sleep and wake up just the firt process. > > -Andi > > ---end quoted text--- From owner-linux-xfs@oss.sgi.com Wed Oct 23 07:53:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 07:53:52 -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 g9NErbuR001216 for ; Wed, 23 Oct 2002 07:53:50 -0700 Received: from fw124 ([192.168.32.1]) by msrv.minfin.govrn.bg (Netscape Messaging Server 3.62) with SMTP id 792 for ; Wed, 23 Oct 2002 17:40:42 +0300 Reply-To: From: "Kostadin Karaivanov" To: Subject: RE: TAKE - Fix root exec access checks on files with acls Date: Wed, 23 Oct 2002 17:42:51 +0300 Message-ID: <006d01c27aa2$775decd0$1504a8c0@larry2> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200210231401.g9NE1Cq10406@stout.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-archive-position: 1202 X-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 Is there any issue with gcc-3.2? I'm getting errors when I try to compile(linking stage I believe) xfsprogs with gcc-3.2. OS is slackware-surrent, glibc 2.3.1. Error is as follows: gcc -o xfs_db addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o strvec.o text.o type.o uuid.o write.o main.o ../libxfs/.libs/libxfs.a /usr/lib/libuuid.a /usr/lib/libuuid.a(parse.o): In function `uuid_parse': parse.o(.text+0x2c): undefined reference to `__ctype_b' collect2: ld returned 1 exit status make[2]: *** [xfs_db] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/cmd/xfsprogs' make: *** [default] Error 2 I suspect that there is a library on my machine that is compiled with older gcc but I can't determine which....... Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 larry@minfin.government.bg 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 23 08:00:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 08:00:21 -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 g9NF0HuR002687 for ; Wed, 23 Oct 2002 08:00:18 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184Mzc-0002z1-00; Wed, 23 Oct 2002 16:00:20 +0100 Date: Wed, 23 Oct 2002 16:00:20 +0100 From: Christoph Hellwig To: Andrew Morton Cc: Luben Tuikov , linux-xfs , Eric Sandeen Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c Message-ID: <20021023160020.B11192@infradead.org> References: <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5EB3E.8A5C1D68@digeo.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: <3DB5EB3E.8A5C1D68@digeo.com>; from akpm@digeo.com on Tue, Oct 22, 2002 at 05:20:14PM -0700 X-archive-position: 1203 X-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 Tue, Oct 22, 2002 at 05:20:14PM -0700, Andrew Morton wrote: > > - > > - if (waitqueue_active(&pb_resv_bh_wait)) { > > - wake_up(&pb_resv_bh_wait); > > - } > > - > > spin_unlock_irqrestore(&pb_resv_bh_lock, flags); > > + wake_up(&pb_resv_bh_wait); > > } > > } > > > > I'd be interested in a description of how this can help > avoid a deadlock. After thinking more about it it probably can't - I was thinking of the case where the waiting threads holds a sleeping lock. I've digged a bit deeper into the code and found the following issues: add_wait_queue(&pb_resv_bh_wait, &wait); do { run_task_queue(&tq_disk); This might take some time, while we're still TASK_RUNNING, try_to_wake_up() will skip us simplly here, we've might lose a waekup. In addition tq function could possibly sleep, although no user of tq_disk in the 2.4 tree does. set_task_state(tsk, TASK_UNINTERRUPTIBLE); spin_unlock_irqrestore(&pb_resv_bh_lock, flags); schedule(); No we schedule away after the lost wakeup. We could get starved pretty soon by new callers putting themselves in front of us in the wq. spin_lock_irqsave(&pb_resv_bh_lock, flags); Luben, could you try to reproduce it with the patch below? (the double condition check might be a bit overdone, but it's a common ideom in the kernel and I rather play save) --- linux/fs/xfs/pagebuf/page_buf.c 2002/10/23 04:21:07 1.71 +++ linux/fs/xfs/pagebuf/page_buf.c 2002/10/23 14:49:01 @@ -657,9 +657,11 @@ _pagebuf_get_prealloc_bh(void) add_wait_queue(&pb_resv_bh_wait, &wait); do { - run_task_queue(&tq_disk); set_task_state(tsk, TASK_UNINTERRUPTIBLE); + if (pb_resv_bh_cnt >= 1) + break; spin_unlock_irqrestore(&pb_resv_bh_lock, flags); + run_task_queue(&tq_disk); schedule(); spin_lock_irqsave(&pb_resv_bh_lock, flags); } while (pb_resv_bh_cnt < 1); From owner-linux-xfs@oss.sgi.com Wed Oct 23 08:02:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 08:02:55 -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 g9NF2muR003285 for ; Wed, 23 Oct 2002 08:02:53 -0700 Received: from fw124 ([192.168.32.1]) by msrv.minfin.govrn.bg (Netscape Messaging Server 3.62) with SMTP id 512 for ; Wed, 23 Oct 2002 18:03:27 +0300 Reply-To: From: "Kostadin Karaivanov" To: Subject: xfsprogs gcc-3.2 Date: Wed, 23 Oct 2002 18:05:38 +0300 Message-ID: <006f01c27aa5$a622db90$1504a8c0@larry2> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <006d01c27aa2$775decd0$1504a8c0@larry2> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-archive-position: 1204 X-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 Again , sorry about repost subject change Is there any issue with gcc-3.2? I'm getting errors when I try to compile(linking stage I believe) xfsprogs with gcc-3.2. OS is slackware-surrent, glibc 2.3.1. Error is as follows: gcc -o xfs_db addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o strvec.o text.o type.o uuid.o write.o main.o ../libxfs/.libs/libxfs.a /usr/lib/libuuid.a /usr/lib/libuuid.a(parse.o): In function `uuid_parse': parse.o(.text+0x2c): undefined reference to `__ctype_b' collect2: ld returned 1 exit status make[2]: *** [xfs_db] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/cmd/xfsprogs' make: *** [default] Error 2 I suspect that there is a library on my machine that is compiled with older gcc but I can't determine which....... Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 larry@minfin.government.bg 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 23 08:04:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 08:04:47 -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 g9NF4guR003862 for ; Wed, 23 Oct 2002 08:04:44 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184N3w-00033G-00; Wed, 23 Oct 2002 16:04:48 +0100 Date: Wed, 23 Oct 2002 16:04:48 +0100 From: Christoph Hellwig To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Fix root exec access checks on files with acls Message-ID: <20021023160448.A11646@infradead.org> References: <200210231401.g9NE1Cq10406@stout.americas.sgi.com> <006d01c27aa2$775decd0$1504a8c0@larry2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <006d01c27aa2$775decd0$1504a8c0@larry2>; from larry@minfin.government.bg on Wed, Oct 23, 2002 at 05:42:51PM +0300 X-archive-position: 1205 X-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 23, 2002 at 05:42:51PM +0300, Kostadin Karaivanov wrote: > Is there any issue with gcc-3.2? > I'm getting errors when I try to compile(linking stage I believe) xfsprogs > with gcc-3.2. > OS is slackware-surrent, glibc 2.3.1. Error is as follows: gcc 3.2 and glibc 2.3 don't play nicely together without additional patches. The glibc FAQ should have a pointer to the required patch. From owner-linux-xfs@oss.sgi.com Wed Oct 23 08:05:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 08:05:49 -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 g9NF5luR004462 for ; Wed, 23 Oct 2002 08:05:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA96995; Wed, 23 Oct 2002 10:05:47 -0500 (CDT) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA38871; Wed, 23 Oct 2002 10:05:47 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9NF5sb9017893; Wed, 23 Oct 2002 10:05:56 -0500 Subject: RE: TAKE - Fix root exec access checks on files with acls From: Russell Cattelan To: larry@minfin.government.bg Cc: linux-xfs@oss.sgi.com In-Reply-To: <006d01c27aa2$775decd0$1504a8c0@larry2> References: <006d01c27aa2$775decd0$1504a8c0@larry2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 10:05:53 -0500 Message-Id: <1035385556.25625.71.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1206 X-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 Wed, 2002-10-23 at 09:42, Kostadin Karaivanov wrote: > Is there any issue with gcc-3.2? > I'm getting errors when I try to compile(linking stage I believe) xfsprogs > with gcc-3.2. > OS is slackware-surrent, glibc 2.3.1. Error is as follows: > > > gcc -o xfs_db addr.o agf.o agfl.o agi.o attr.o attrshort.o bit.o block.o > bmap.o bmapbt.o bmroot.o bnobt.o check.o cntbt.o command.o convert.o data.o > dbread.o debug.o dir.o dir2.o dir2sf.o dirshort.o dquot.o echo.o faddr.o > field.o flist.o fprint.o frag.o freesp.o hash.o help.o init.o inobt.o > inode.o input.o io.o malloc.o mount.o output.o print.o quit.o sb.o sig.o > strvec.o text.o type.o uuid.o write.o main.o ../libxfs/.libs/libxfs.a > /usr/lib/libuuid.a > /usr/lib/libuuid.a(parse.o): In function `uuid_parse': > parse.o(.text+0x2c): undefined reference to `__ctype_b' > collect2: ld returned 1 exit status > make[2]: *** [xfs_db] Error 1 > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/cmd/xfsprogs' > make: *** [default] Error 2 > > I suspect that there is a library on my machine that is compiled with older > gcc but I can't > determine which....... I would guess libuuid is a good place to start :-) that library is part of the ext2 devel package. > > > > Kostadin Karaivanov > Senior System Administrator @ Ministry Of Finance > tel: +359 2 98592062 > larry@minfin.government.bg > > > 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 23 08:23:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 08:23:42 -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 g9NFNduR010568 for ; Wed, 23 Oct 2002 08:23:40 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA20095; Wed, 23 Oct 2002 10:23:42 -0500 (CDT) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA37140; Wed, 23 Oct 2002 10:23:41 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9NFNnb9017917; Wed, 23 Oct 2002 10:23:50 -0500 Subject: Re: RH 8.0 installer From: Russell Cattelan To: Paulo Matos Cc: linux-xfs@oss.sgi.com, Eric Sandeen In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 10:23:48 -0500 Message-Id: <1035386630.25622.90.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 g9NFNeuR010572 X-archive-position: 1207 X-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 Tue, 2002-10-22 at 16:06, Paulo Matos wrote: > Hi all! Hi Russell! > > On 22 Oct 2002, Eric Sandeen wrote: > > sandeen> Yep, it's Russell Cattelan here at SGI, he originally posted the > sandeen> message that the installer was released, along with all the > sandeen> caveats. > sandeen> > sandeen> Feel free to just send bug reports (and patches...) to > sandeen> the list, though. > sandeen> > sandeen> 1.2pre2 will be populated when it's available... > > Does 'pre2' refers to XFS or to the installer? XFS The installer iso probably won't be respun until 1.2 is final. > > Looking at .discinfo: > 1031690066.345824 > Psyche 8.0 > i386 > 6 > RedHat/base > RedHat/RPMS > RedHat/pixmaps > > i noticed that 'RedHat/pixmaps' does not exists on CD image... don't know > if this matters or not... I don't think so, all the RH cd's have that format for the .discid file so I just copied the format. > > Are images/boot*.img XFS ready? I'm asking this because on > previous releases I could never fit a XFS kernel on a normal 1.44M disk ;) yes they are xfs ready but they do not contain xfs itself. XFS is loaded as a module that is extracted from the stage2.img. > > I'll start testing this out ... (DISK/CD/FTP/HTTP + > text/graphic/kickstart) Note text does not work unless you pre-partition your disk. > > -- > Paulo Matos > ----------------------------------- ---------------------------------- > |Sys & Net Admin | Servi鏾 de Inform醫ica | > |Faculdade de Ci阯cias e Tecnologia | Tel: +351-21-2948596 | > |Universidade Nova de Lisboa | Fax: +351-21-2948548 | > |P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt | > ----------------------------------- ---------------------------------- > > From owner-linux-xfs@oss.sgi.com Wed Oct 23 09:24:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 09:24:05 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NGO2uR028205 for ; Wed, 23 Oct 2002 09:24:03 -0700 Subject: Share suddenly empty Date: Wed, 23 Oct 2002 12:24:05 -0400 Message-ID: <5A2E4FE5C3D6544D94403072129E30D903A164@cli_exch_one.complexlit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: Share suddenly empty X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcJ6sJrfBpZzPCbNTWKlrV75WjP//w== X-Priority: 1 Priority: Urgent Importance: high From: "Brian Gulizia" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NGO3uR028216 X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Hi, For some reason one of the shares that is critical to our operation has disappeared. People were complaining that they were no longer able to access certain shares so we decided to reboot the server. (when we looked at it, the server was acting very sluggish) When the server came back up, one of our shares was missing. I received an error message of /dev/sdb not a valid block device on bootup and when I tried to manually mount the volume. (sdb is an attached raid array) We powered everything down and back up again, and we did not receive the error, but when we looked at the share we noticed that it had absolutely nothing in it. We used KDiskfree and saw that the share does in fact have something on it, because 68% of the drive is showing used. I have read these newsgroups and saw mention of an xfs_repair and an xfs_check command. I unmounted the share and started to run xfs_check and an impossibly large list started scrolling by talking about bad blocks. I saw one post that mentioned running xfs_repair -L but I am unclear how the xfs_repair will work as well as what the -L option does. I was hoping to garner some more information before running the xfs_repair command as some of the data will be hard to replace. Any advice would be greatly appreciated. Brian Gulizia From owner-linux-xfs@oss.sgi.com Wed Oct 23 09:33:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 09:33:07 -0700 (PDT) Received: from 202.106.107.234 (w148.z209220087.chi-il.dsl.cnc.net [209.220.87.148]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NGX3uR008313 for ; Wed, 23 Oct 2002 09:33:04 -0700 Message-Id: <200210231633.g9NGX3uR008313@oss.sgi.com> Received: from unknown (26.113.85.29) by smtp4.cyberec.com with esmtp; Oct, 23 2002 11:25:54 AM +0700 Received: from unknown (52.127.142.42) by rly-xl04.mx.aol.com with smtp; Oct, 23 2002 10:06:43 AM +0700 Received: from unknown (134.164.251.44) by mail.gmx.net with asmtp; Oct, 23 2002 9:29:52 AM +0300 Received: from rly-xl04.mx.aol.com ([161.143.46.72]) by m10.grp.snv.yahoo.com with QMQP; Oct, 23 2002 8:31:56 AM +1100 From: "WALL STREET BULLETIN..47658" To: Subscriber.Acct.#99804@oss.sgi.com Cc: Subject: NEW STOCK PICK: PRCT - LAST PICK UP 233%, NNCO............................................................................................................................................................................................... shbmn Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 23 Oct 2002 11:35:03 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) X-Priority: 1 X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Subscriber_Services78039@penn.com Precedence: bulk X-list: linux-xfs

Did you miss out on NNCO, UP 233% IN JUST 2 DAYS?

If so, Here's another pick - Another Short Play

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

mqkcqvohojpobbtobbndqq From owner-linux-xfs@oss.sgi.com Wed Oct 23 09:33:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 09:33:18 -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 g9NGXGuR008379 for ; Wed, 23 Oct 2002 09:33:16 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA82869; Wed, 23 Oct 2002 11:33:18 -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 LAA35623; Wed, 23 Oct 2002 11:33:18 -0500 (CDT) Subject: Re: Share suddenly empty From: Eric Sandeen To: Brian Gulizia Cc: linux-xfs@oss.sgi.com In-Reply-To: <5A2E4FE5C3D6544D94403072129E30D903A164@cli_exch_one.complexlit.com> References: <5A2E4FE5C3D6544D94403072129E30D903A164@cli_exch_one.complexlit.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 23 Oct 2002 11:28:48 -0500 Message-Id: <1035390528.10487.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1210 X-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 Wed, 2002-10-23 at 11:24, Brian Gulizia wrote: > Hi, > > For some reason one of the shares that is critical to our operation has disappeared. > People were complaining that they were no longer able to access certain shares so we decided > to reboot the server. (when we looked at it, the server was acting very sluggish) > When the server came back up, one of our shares was missing. I received an error message > of /dev/sdb not a valid block device on bootup and when I tried to manually mount the volume. > (sdb is an attached raid array) > We powered everything down and back up again, and we did not receive the error, but when > we looked at the share we noticed that it had absolutely nothing in it. We used KDiskfree > and saw that the share does in fact have something on it, because 68% of the drive is showing > used. > > I have read these newsgroups and saw mention of an xfs_repair and an xfs_check command. > I unmounted the share and started to run xfs_check and an impossibly large list started scrolling > by talking about bad blocks. I saw one post that mentioned running xfs_repair -L but I am unclear > how the xfs_repair will work as well as what the -L option does. I was hoping to garner some more > information before running the xfs_repair command as some of the data will be hard to replace. If you saw a message about "xfs_repair -L," that is telling you that the filesystem has a dirty log, and it should be mounted & cleanly unmounted before xfs_repair will tell you anything meaningful. the -L option will clear out the log and continue, but you DO NOT WANT TO DO THIS unless you cannot mount the filesystem due to log corruption, you will irreversibly lose valuable metadata with this option. Once again, for clarity: DO NOT RUN xfs_repair -L UNLESS YOU HAVE TRIED TO CLEANLY MOUNT & UNMOUNT FIRST. Try mounting & unmounting the filesystem, then run xfs_check and xfs_repair -n, and save the output. (-n tells repair to not actually do anything yet). -Eric > Any advice would be greatly appreciated. > > Brian Gulizia > -- 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 23 10:42:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 10:42:51 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NHgnuR017805 for ; Wed, 23 Oct 2002 10:42:49 -0700 Subject: RE: Share suddenly empty Date: Wed, 23 Oct 2002 13:42:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5A2E4FE5C3D6544D94403072129E30D92B8918@cli_exch_one.complexlit.com> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Share suddenly empty Thread-Index: AcJ6selpCvpKl64pTCS/wwlQVRvZ6wACZI5Q From: "Brian Gulizia" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NHgnuR017829 X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs I can mount the filesystem, but when i do an ls -l or an ls -al it shows absolutely nothing. But, as I mentioned earlier if I look in KDiskfree it shows that there is something on the drive. I ran the xfs_repair -r /dev/sdb command and received the following: Phase 1 - find and veryify superblock... Phase 2 - using internal log - scan filesystem freespace It is at this point that all hell broke loose. Many, many lines of: bad magic #number for agf0 bad version #number for agf0 bad length..... bad(negative)side.... after running for a few minutes, scrolling on and on I started receiving strange characters, not in legible english. 1) do you know what could have caused this? 2) how do I proceed from here? I've read on one site to run the command without the -n a few times to see how much it can do, then do mount the device in read only, make a filesystem backup with xfs dump, use mkfs to make a new filesytem and then do an xfsrestore. Any suggestions? Brian On Wed, 2002-10-23 at 11:24, Brian Gulizia wrote: > Hi, > > For some reason one of the shares that is critical to our operation has disappeared. > People were complaining that they were no longer able to access certain shares so we decided > to reboot the server. (when we looked at it, the server was acting very sluggish) > When the server came back up, one of our shares was missing. I received an error message > of /dev/sdb not a valid block device on bootup and when I tried to manually mount the volume. > (sdb is an attached raid array) > We powered everything down and back up again, and we did not receive the error, but when > we looked at the share we noticed that it had absolutely nothing in it. We used KDiskfree > and saw that the share does in fact have something on it, because 68% of the drive is showing > used. > > I have read these newsgroups and saw mention of an xfs_repair and an xfs_check command. > I unmounted the share and started to run xfs_check and an impossibly large list started scrolling > by talking about bad blocks. I saw one post that mentioned running xfs_repair -L but I am unclear > how the xfs_repair will work as well as what the -L option does. I was hoping to garner some more > information before running the xfs_repair command as some of the data will be hard to replace. If you saw a message about "xfs_repair -L," that is telling you that the filesystem has a dirty log, and it should be mounted & cleanly unmounted before xfs_repair will tell you anything meaningful. the -L option will clear out the log and continue, but you DO NOT WANT TO DO THIS unless you cannot mount the filesystem due to log corruption, you will irreversibly lose valuable metadata with this option. Once again, for clarity: DO NOT RUN xfs_repair -L UNLESS YOU HAVE TRIED TO CLEANLY MOUNT & UNMOUNT FIRST. Try mounting & unmounting the filesystem, then run xfs_check and xfs_repair -n, and save the output. (-n tells repair to not actually do anything yet). -Eric > Any advice would be greatly appreciated. > > Brian Gulizia > -- 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 23 11:13:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 11:13:06 -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 g9NID3uR021610 for ; Wed, 23 Oct 2002 11:13:04 -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 g9NID799002608; Wed, 23 Oct 2002 20:13:08 +0200 (CEST) Message-Id: <4.3.2.7.2.20021023200632.03ba0030@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Oct 2002 20:11:59 +0200 To: "Brian Gulizia" , From: Seth Mos Subject: RE: Share suddenly empty In-Reply-To: <5A2E4FE5C3D6544D94403072129E30D92B8918@cli_exch_one.comple xlit.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1212 X-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:42 23-10-2002 -0400, Brian Gulizia wrote: >I can mount the filesystem, but when i do an ls -l or an ls -al it shows >absolutely nothing. >But, as I mentioned earlier if I look in KDiskfree it shows that there is >something on the drive. probably in the lost+found directory If the system crashed and you didn't let the kernel do recovery by mounting it and just "repaired" it you probably did more damage then good. First let the filesystem do recovery and if that fails it will be a good time to use xfs_repair. I always do a "xfs_repair -n" before performing the actual repair to see what is damaged. I have never had to use a xfs_repair with the -L option yet. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Oct 23 11:37:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 11:37:44 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NIbguR025326 for ; Wed, 23 Oct 2002 11:37:42 -0700 Subject: RE: Share suddenly empty Date: Wed, 23 Oct 2002 14:37:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5A2E4FE5C3D6544D94403072129E30D903A166@cli_exch_one.complexlit.com> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Share suddenly empty Thread-Index: AcJ6v9jrh7RB0NQiSQemLwYLtXG9HwAAqbfQ From: "Brian Gulizia" To: "Seth Mos" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NIbhuR025345 X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs I hadnt done anything to it. All I did was reboot, I got the "not a valid block device" when i tried to mout it, rebooted again and was able to mount it but it has nothing on it when I do an ls. You'll have to excuse my newbieness, but when you say let the filesystem do recovery, what do you mean? I didnt see anything about the kernel doing any recovering. Brian -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Wednesday, October 23, 2002 2:12 PM To: Brian Gulizia; linux-xfs@oss.sgi.com Subject: RE: Share suddenly empty At 13:42 23-10-2002 -0400, Brian Gulizia wrote: >I can mount the filesystem, but when i do an ls -l or an ls -al it shows >absolutely nothing. >But, as I mentioned earlier if I look in KDiskfree it shows that there is >something on the drive. probably in the lost+found directory If the system crashed and you didn't let the kernel do recovery by mounting it and just "repaired" it you probably did more damage then good. First let the filesystem do recovery and if that fails it will be a good time to use xfs_repair. I always do a "xfs_repair -n" before performing the actual repair to see what is damaged. I have never had to use a xfs_repair with the -L option yet. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Oct 23 11:43:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 11:43:48 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9NIhkuR026375 for ; Wed, 23 Oct 2002 11:43:46 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9NIhk09026374 for linux-xfs@oss.sgi.com; Wed, 23 Oct 2002 11:43:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9NIhiuT026358 for ; Wed, 23 Oct 2002 11:43:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9NIhWCH026329; Wed, 23 Oct 2002 11:43:32 -0700 Date: Wed, 23 Oct 2002 11:43:32 -0700 Message-Id: <200210231843.g9NIhWCH026329@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From juri@koschikode.com 2002-10-23 11:43 ------- Ok, another "me too" report: Kernel checked out and build on 2002-10-06, XFS-specific part of .config: CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set The /home partition of my little server @home suddenly vanished. After a reboot the filesystem was mounted w/o problems but to be sure I unmounted it and ran xfs_check on my /home partition but without getting any errors. Now it happened again. On the first mount of the partition the XFS recovery process was started. Here are the log entries for the to incidents: Oct 16 22:13:52 warp9 kernel: xfs_force_shutdown(ide2(33,5),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xc01f9774 Oct 16 22:13:52 warp9 kernel: Corruption of in-memory data detected. Shutting down filesystem: ide2(33,5) Oct 23 20:06:44 warp9 kernel: xfs_force_shutdown(ide2(33,5),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xc01f9774 Oct 23 20:06:44 warp9 kernel: Corruption of in-memory data detected. Shutting down filesystem: ide2(33,5) This server is mainly serving email, NFS and Samba. Regards, Juri ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 23 12:13:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 12:13:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9NJDjuR030031 for ; Wed, 23 Oct 2002 12:13:45 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9NJDjcK030030 for linux-xfs@oss.sgi.com; Wed, 23 Oct 2002 12:13:45 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9NJDiuV030009 for ; Wed, 23 Oct 2002 12:13:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9NIisKh026631; Wed, 23 Oct 2002 11:44:54 -0700 Date: Wed, 23 Oct 2002 11:44:54 -0700 Message-Id: <200210231844.g9NIisKh026631@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 juri@koschikode.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |juri@koschikode.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 23 14:08:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 14:08:42 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NL8cuR007276 for ; Wed, 23 Oct 2002 14:08:38 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9NL8WaF017791 for ; Wed, 23 Oct 2002 16:08:32 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9NL7WHK017720; Wed, 23 Oct 2002 16:07:32 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Recent XFS benchmarks? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 16:06:32 -0500 Message-Id: <1035407192.16632.5.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1216 X-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 Is there a link for recent XFS benchmarks? I've got a DBA with some questions, and I'd like something to back them up a bit. TIA Austin From owner-linux-xfs@oss.sgi.com Wed Oct 23 14:29:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 14:29:40 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NLTbuR009250 for ; Wed, 23 Oct 2002 14:29:38 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g9NLThn6079787; Wed, 23 Oct 2002 23:29:44 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g9NLTh191151; Wed, 23 Oct 2002 23:29:43 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 23 Oct 2002 23:29:43 +0200 (CEST) From: Seth Mos To: Brian Gulizia cc: linux-xfs@oss.sgi.com Subject: RE: Share suddenly empty In-Reply-To: <5A2E4FE5C3D6544D94403072129E30D903A166@cli_exch_one.complexlit.com> Message-ID: <20021023232212.N90674-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1217 X-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, 23 Oct 2002, Brian Gulizia wrote: > I hadnt done anything to it. All I did was reboot, I got the "not a valid block > device" when i tried to mout it, rebooted again and was able to mount it but it has > nothing on it when I do an ls. You'll have to excuse my newbieness, but when you > say let the filesystem do recovery, what do you mean? I didnt see anything about the > kernel doing any recovering. The recovery part is something the filesystem does after a "unclean unmount" eg. poweroff. When you mount the filesystem it would be done automatically. If recovery was required there will be a message during the mount of the filesystem. And if I am right there should at least be a message in you /var/log/messages (or equivalent) stating that there was a filesystem error. If not from the just attempted mount there should at least be one from when the files first "dissappeard". Did you already repair the filesystem per chance? Check with mount if it is unmounted. xfs_repair -n /dev/sdb? or xfs_check /dev/sdb? and check for errors or other problems it finds. Mail that back to the list (zipped please). If there is nothing serious in there you could attempt a repair of the filesystem if you are couragesous ;-) I'm going to bed here, maybe someone from america can pick this up *hint* See you in 8 hours. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Oct 23 15:22:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 15:22:25 -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 g9NMMNuR018430 for ; Wed, 23 Oct 2002 15:22:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA68564 for ; Wed, 23 Oct 2002 17:22:27 -0500 (CDT) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA31517 for ; Wed, 23 Oct 2002 17:22:26 -0500 (CDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9NMMRkq002158 for ; Wed, 23 Oct 2002 17:22:27 -0500 Subject: XFS 1.2pre2 available From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 17:22:27 -0500 Message-Id: <1035411747.1231.7.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1218 X-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 Well actually it's been there since Friday but not all the rpm's were built. Thanks to Christoph the RH rpm's are not based off of the 2.4.18-17 build from RedHat. Here it the change log since 1.2 pre1 Changes in 1.2-pre2: * Backport faster 8-byte swap from 2.5 * Prevent blocks from being put on XFS's "busy list" twice. * Rearrange how xfs deals with read-only mounts vs. read-only devices. 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. Remove the vfs read-only checks for various xfs operations, just check whether the underlying device is read-only * 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. * fix alloc busy list off by one errors, and simplify the bounds check code. * 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. From owner-linux-xfs@oss.sgi.com Wed Oct 23 15:36:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 15:36:10 -0700 (PDT) Received: from WilsonCO.simflex.com (www.simflex.com [206.153.0.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NMa7uR020036 for ; Wed, 23 Oct 2002 15:36:08 -0700 Received: from ccdmerchandise.com (WilsonCO.simflex.com [206.153.0.2]) by WilsonCO.simflex.com (8.12.5/8.12.5) with SMTP id g9NMfsfL004705 for ; Wed, 23 Oct 2002 18:41:54 -0400 Received: from 206.153.21.5 (SquirrelMail authenticated user admin) by mail.ccdmerchandise.com with HTTP; Wed, 23 Oct 2002 18:41:54 -0400 (EDT) Message-ID: <3413.206.153.21.5.1035412914.squirrel@mail.ccdmerchandise.com> Date: Wed, 23 Oct 2002 18:41:54 -0400 (EDT) Subject: RedHat 8.0 Installer From: "Doug Eubanks" To: X-Priority: 3 Importance: Normal Reply-To: doug@simflex.com X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doug@simflex.com Precedence: bulk X-list: linux-xfs Is anyone using the Release-1.2pre1 RedHat Installer in production? I have been using the installers for quite a while now and I need to redo a server (that gets quite a bit of load) and I HATE EXT3. I was hoping to get some feedback from someone who has used this version with RH8 Thanks, Sincerely, Doug Eubanks doug@simflex.com ----------------------------------------- This email was sent from ccdmerchandise.com. It has been certified virus free! Visit us online at http://www.ccdmerchandise.com From owner-linux-xfs@oss.sgi.com Wed Oct 23 18:43:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 18:43:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9O1hkuR030960 for ; Wed, 23 Oct 2002 18:43:46 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9O1hkGk030959 for linux-xfs@oss.sgi.com; Wed, 23 Oct 2002 18:43:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9O1hiuV030939 for ; Wed, 23 Oct 2002 18:43:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9O1SIWF030217; Wed, 23 Oct 2002 18:28:18 -0700 Date: Wed, 23 Oct 2002 18:28:18 -0700 Message-Id: <200210240128.g9O1SIWF030217@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-10-23 18:28 ------- Hi Juri - This is a different problem (both are force shutdowns, but yours is for a different reason). Looks like yours was cancelling a dirty transaction, and I don't know what the cause might be. You can open a new bug on this if you'd like, but this is a tough one to fix, since it's not easily repeatable. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Oct 23 20:47:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 20:47:24 -0700 (PDT) Received: from 213.250.162.7 ([213.250.162.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O3lEuR005973 for ; Wed, 23 Oct 2002 20:47:17 -0700 Message-Id: <200210240347.g9O3lEuR005973@oss.sgi.com> Received: from [41.237.71.37] by f64.law4.hotmail.com with NNFMP; Oct, 24 2002 11:46:25 AM +0600 Received: from unknown (HELO smtp4.cyberec.com) (24.156.151.193) by rly-xw05.mx.aol.com with esmtp; Oct, 24 2002 10:27:21 AM -0700 Received: from unknown (189.234.223.231) by rly-xr02.mx.aol.com with esmtp; Oct, 24 2002 9:37:06 AM -0100 From: Marketing Now To: linux-xfs@oss.sgi.com Cc: Subject: Business Marketing on The Web Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Thu, 24 Oct 2002 11:47:33 +0800 X-Mailer: Microsoft Outlook IMO Build 9.0.2416 (9.0.2910.0) X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tunywe@hotmail.com Precedence: bulk X-list: linux-xfs WEBMarketing ...beyond the basics

This offer valid only till October 29th, 2002

Internet Marketing - beyond the basics
A new way to do business that will change business forever and unleash unlimited prosperity to those who learn these secrets....

For the next 72 hours you can take advantage of this very special offer:

WEBMarketing ...beyond the basics 
 The Manual that "let's you in on the Secrets and Tricks of The Trade ."

Just US$149 - delivered to your door - anywhere in the world
The Authoritative Source of Web Marketing for Business with over 200 pages of the latest techniques for successful Internet Marketing - just US$149 covering everything from Search Engine Optimisation, Permission Marketing Techniques, Viral Marketing, Multi Domain Registration, Opt-In Mail Lists, Competition Sites and much more.

Review examples of 37 successful websites that will make your mouth water in anticipation of success. Sites that attract 60,000 Unique Visitors a week - where the average Website has only 200 Unique Visitors a YEAR! See how low budgets sites have created 20,000, 200,000, 300,000 and even 400,000 opt-in email databases with quirky and unusual strategies.

 

WEBMarketing ...beyond the basics covers little known "Trade Secrets" that unlock the money making potential for Business Marketing on the Web including:

Understanding The Medium
A guide to all the Internet's language, systems, terms and Internet Savy.

Effective On-line Marketing
Examine promotional, advertising, marketing and sales goals for realistic on-line marketing efforts and look at ways to measure their results.

Permission Marketing
What works and what doesn't! Claim the Internet for your business the future of the Internet - Permission Marketing.

Grab Attention On-Line. 
Learn how to create attention getting stand out marketing campaigns and advertising in the vast, unmapped cyberspace.

Viral Marketing 
 Grow you business the way hotmail exploded - use the power of word of mouth referrals speed up by Internet connectivity.

eMail Marketing Tips and Tricks

In addition to being a dynamic, affordable marketing tool, eMail newsletters are one of the best ways to promote a web site and give you and an excuse to capture valuable data to use for other marketing campaigns.

Opt-In Database Marketing 
Learn this skill and you will dramatically increase your business and profits.

Newsletters Are The REAL Success Story
Learn why HTML newsletters have become the star application of Internet Marketing in 2002. Review 5 of the most effective email newsletters currently being sent to opt in databases. Whether the list is 500, 5,000 or 50,000 strong, these exquisite marketing tools are just fantastic.

Winning the Privacy Act changes
There is nothing to fear with the recent changes to the Privacy Act. Learn what you need to do, how easy it is to turn the changes into a bonus and see samples of Privacy Statements for marketers

Maximising Search Engines 
The number of web pages has exceeded 1 billion and the search engines aren't keeping up. Learn strategies to keep you in front of the pack.

Success Stories
We share with you practical examples of the success of companies using WebMarketing techniques. Companies without multimillion dollar budgets - creative ideas and a track to run on give outstanding success. 

On-Line Marketing Plans
There's always a plan behind every brilliant marketing strategy. To make money on the Internet you need to know how to clearly identify your objectives and realise your goals.

Building an Internet Marketing Effort.
What's it cost and what can you expect.... you can do it yourself for free or you can pay for the best advice. What's best for you?

All this and more...

BONUS OFFER - MAKE NO MISTAKE ABOUT IT!

Email marketing either to Opt-In Databases or as Targeted Direct marketing will give you a profitable return quicker than any other form of marketing effort. There are millions of responsive buyers out there for just about anything you have to sell. Our bonus offer includes everything you need to make a start on creating your own WebMarketing success - all on one CD!

Order within 72 hours and the following bonuses are yours  -  FREE OF CHARGE

  • Bonus Offer 1 - Special Sealed Section - TOTALLY REVISED for 2002
    We let you into the secrets that allowed Australia's leading business seminar company to attract 11,762 attendees from over 3,543 businesses to seminars across the country. Techniques that have generated in excess of $1 million of income in less than 12 months for cost of a high speed ADSL internet connection. 

    This comprehensive guide to making e-mail marketing work in Australia shows how to send email messages without upsetting your ISP. These techniques work where ever you are in the world! Don't believe what you hear about direct email marketing not working. Read for yourself "the real truth" of how you can turn your business around using commercial direct email. This information is not available anywhere else on the Internet. It is easily worth $99.95 but is yours FREE if you act before the deadline.

  • Bonus Offer 2 - Business Web Addresses
    50,000 business web addresses suitable for general marketing ready to be used with your selection of software to create your own fresh list of targeted email addresses. This will save you hours of work and is easily valued at $149
    Yours FREE

  • Bonus Offer 3 - The ULTIMATE Direct Marketers Resource Kit updated June 2002
    All in one place, the most comprehensive list of Internet Direct Marketing resources and services currently available.

    We have included working versions of over 20 of the Worlds best direct marketing software programs. That's right, the very best programs available ready for you to try before you buy. If you like them its easy to register them and get working flat out. Stop searching for sending programs, collection programs, list management programs... they are all here, ready for you.

    Plus, the most comprehensive list of affiliate marketing programs we could find. You will on your way to making a SUBSTANTIAL income from selling the best resources available on the 'net - even becoming a virtual store amazon.com if you like, or web guru Cory Rudel.
    Yours FREE

The WebMarketing Manual has helped over 4,000 small, medium or large companies in the last 12 months to gain an "unfair advantage" on their competition. Whether the companies have been sole traders such as a mom and pop enterprises through to major corporations like major banks, retailers, wholesalers and catalogue houses, they have applied the messages contained in this best selling manual and experienced extraordinary results.

There is no time to waste. Act now and start enjoying the success you deserve.

This exciting manual is published by The Maverick Partnership, a division of Australia's leading business publishing and seminar company. Companies world wide have used Australian expertise to scale the heights of international business success. 

The Aussies are universally respected for achieving outrageous success. Whether it be staging the Sydney Olympics, Rugby's World Cup, winning the America's Cup, creating the world's greatest media empire like Rupert Murdoch's News Corporation or Qantas the world's most profitable and safest airline. The isolation of Australia, its massive land mass and small population has created a nation of high achievers. Aussie sportspeople over achieve - Lleyton Hewett is No 1 in tennis, Greg Norman dominated golf courses for a decade, Ian Thorpe smashed 20 world swimming records before he was 21; in entertainment - Mel Gibson, Russell Crowe and Nicole Kidman are setting box office records in the movies.

So, don't delay, order WebMarketing beyond the basics and start getting results.

How to order:

  1. By eMail
    Complete the form below & click 'submit'
  2. By fax
    Print the form below, complete & send to +618 6210 1445
  3. By phone
    Call +618 6210 1348
Yes! Rush me WEBMarketing ...beyond the basics with my free bonus offers
Number  @ US$149 - delivered to anywhere in the world
First Name  
Last Name  
Company
Position
Address  
Address Cont.
City
State
Post Code  
Country
Phone  
Fax
e-Mail
Web Site

Payment Details:
Credit Card  

Cardholder Name
Card Number
Expiry Date

smsg2910
Don't Delay - Offer  expires October 29th... Don't Miss Out!

Your booking form is sent by eMail - just check your 'Sent Items'  to confirm that it has been submitted successfully.

You are important to us. If you are having problems ordering, please let us know by eMail or phone +618 6210 1348 

Any questions?? Feel free to contact us and we'll explain the unique advantages of this particular offer but remember this offer EXPIRES on October 29th, 2002!

The Maverick Partnership
A division of The Which Company Pty Ltd
ABN: 90 091 728 620
Corporate Office: 42 Wickham Street, East Perth, Western Australia, Australia
Offices in: Sydney, Melbourne, Brisbane, Adelaide, Perth
Postal Address: PO Box 159, Northbridge, 6865 Western Australia, Australia
Within Australia Phone: 08 6210 1348 Fax: 08 6210 1445
Internationally Phone: +618 6210 1348 Fax: +618 210 1445

This is being sent to: linux-xfs@oss.sgi.com
We collect eMail contact addresses from various publicly available sources and other marketing promotions. We understand you may wish NOT to receive information from us by eMail.

To be removed from this and other offers, do not reply to sender, simply click here to send an email with "REMOVE linux-xfs@oss.sgi.com" in the subject line or phone +618 6210 1348  or  fax details to +618 6210 1445

 
From owner-linux-xfs@oss.sgi.com Wed Oct 23 20:49:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 20:49:10 -0700 (PDT) Received: from hotmail.com ([218.22.32.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O3n4uS006187 for ; Wed, 23 Oct 2002 20:49:07 -0700 Date: Wed, 23 Oct 2002 20:49:07 -0700 Message-Id: <200210240349.g9O3n4uS006187@oss.sgi.com> From: =?GB2312?B?zfTR8w==?= Subject: =?GB2312?B?0ru49s7S0rLU+L6tsrvP4NDFo6y1q8i0ysfV5sq1tcS5ysrCINTCytXI68r9?= X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wongrs385@hotmail.com Precedence: bulk X-list: linux-xfs =?GB2312?B?x6fUqs7S1/a1vcHLo6E=?= To: linux-xfs@oss.sgi.com Content-Type: text/plain;charset="GB2312" Date: Thu, 24 Oct 2002 11:51:56 +0800 X-Priority: 3 X-Mailer: EhooPost 2002c 一个我也曾经不相信，但却是真实的故事 月收入数千元我做到了！： http://218.22.32.12/index.asp 在网上混了这么多年，我从不相信网络能赚到一分钱的，我觉得这些说免费赚钱都是骗我们这些网民的。 但一个偶然的机会，在QQ上认识了网上淘金这个家伙， 介绍我到蜘蛛网里看看，他说他本个月赚了1200元，让我也加入做他的下线！我心里想“又是骗人的！” 不过想想反正这么有空，就试试吧！这里有信息看，反正自己也是需要的，赚不了钱也没有关系，于是 花了80元注册了一个用户，收到入会账号！我开始进行发邮件，呵呵！第一个月只得220元，但真有钱哟！ 从不相信的我有了信心，更加努力了，第二个月(6月份）到了2350元，比打工好多了！这些可是我在工作 之余晚上兼职拿到的哟！ 它可靠之处在于有后台管理程序，你可以清淅地看到多少人访问，有多少人注册，你从中得到多钱，非常清楚！ 绝对搞不了欺骗手段，这正是它独特之处 花几分钟进去看看你可以会改变网上赚钱的看法 http://218.22.32.12/index.asp From owner-linux-xfs@oss.sgi.com Wed Oct 23 21:04:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 21:04:48 -0700 (PDT) Received: from hotmail.com ([218.22.32.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O44fuS008325 for ; Wed, 23 Oct 2002 21:04:44 -0700 Date: Wed, 23 Oct 2002 21:04:44 -0700 Message-Id: <200210240404.g9O44fuS008325@oss.sgi.com> From: =?GB2312?B?zfTR8w==?= Subject: =?GB2312?B?0ru49s7S0rLU+L6tsrvP4NDFo6y1q8i0ysfV5sq1tcS5ysrCINTCytXI68r9?= X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wongrs385@hotmail.com Precedence: bulk X-list: linux-xfs =?GB2312?B?x6fUqs7S1/a1vcHLo6E=?= To: linux-xfs@oss.sgi.com Content-Type: text/plain;charset="GB2312" Date: Thu, 24 Oct 2002 12:07:34 +0800 X-Priority: 3 X-Mailer: EhooPost 2002c 一个我也曾经不相信，但却是真实的故事 月收入数千元我做到了！： http://218.22.32.12/index.asp 在网上混了这么多年，我从不相信网络能赚到一分钱的，我觉得这些说免费赚钱都是骗我们这些网民的。 但一个偶然的机会，在QQ上认识了网上淘金这个家伙， 介绍我到蜘蛛网里看看，他说他本个月赚了1200元，让我也加入做他的下线！我心里想“又是骗人的！” 不过想想反正这么有空，就试试吧！这里有信息看，反正自己也是需要的，赚不了钱也没有关系，于是 花了80元注册了一个用户，收到入会账号！我开始进行发邮件，呵呵！第一个月只得220元，但真有钱哟！ 从不相信的我有了信心，更加努力了，第二个月(6月份）到了2350元，比打工好多了！这些可是我在工作 之余晚上兼职拿到的哟！ 它可靠之处在于有后台管理程序，你可以清淅地看到多少人访问，有多少人注册，你从中得到多钱，非常清楚！ 绝对搞不了欺骗手段，这正是它独特之处 花几分钟进去看看你可以会改变网上赚钱的看法 http://218.22.32.12/index.asp From owner-linux-xfs@oss.sgi.com Wed Oct 23 21:21:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 21:21:16 -0700 (PDT) Received: from mesme.codns.com ([61.255.231.144]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O4LDuR009610 for ; Wed, 23 Oct 2002 21:21:13 -0700 Received: (from nobody@localhost) by mesme.codns.com (8.11.6/8.11.6) id g9O3aDe19783 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 12:36:13 +0900 Date: Thu, 24 Oct 2002 12:36:13 +0900 From: ezzl@ezzl.com Message-Id: <200210240336.g9O3aDe19783@mesme.codns.com> X-Authentication-Warning: mesme.codns.com: nobody set sender to ezzl@ezzl.com using -f To: linux-xfs@oss.sgi.com Subject: =?ISO-8859-1?Q?[=B1=A4=20=B0=ED]=20=BA=CE=BA=CE=BB=FD=C8=B0?= =?ISO-8859-1?Q?=BF=EB=C7=B0,=20=B0=A1=C0=BB?= =?ISO-8859-1?Q?=C6=AF=B0=A1=C0=FC-(=B8=B6=C0=BD=B4=EB=B7=CE?= =?ISO-8859-1?Q?=B0=ED=B8=A3=BC=BC=BF=E4~)?= Content-Type: text/html;charset=EUC-KR X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ezzl@ezzl.com Precedence: bulk X-list: linux-xfs Mail
 
己疙 林刮锅龋 -
From owner-linux-xfs@oss.sgi.com Wed Oct 23 23:09:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Oct 2002 23:10:00 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm3.tiscalinet.be [212.35.2.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O69tuR018675 for ; Wed, 23 Oct 2002 23:09:56 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscali) id 184bC1-0004Sa-00; Thu, 24 Oct 2002 08:10:05 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Thu, 24 Oct 2002 08:09:53 +0200 Date: Thu, 24 Oct 2002 08:09:53 +0200 Message-ID: <3DA3C54C00002AA5@ocpmta5.be.tiscali.com> From: jsoe0708@tiscali.be Subject: XFS (CVS release) problem: mkfs.xfs failed on hppa To: linux-xfs@oss.sgi.com Cc: "Stephen Lord" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs Hi all, I build a xfs-kernel (20021022) diff versus 2.4.19 vanilla kernel, apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable (and operational) kernel. Now I rebuild debian package of xfsprogs-2.3.5 (cvs form) and obtain tools binaries (without any warning or error) but even mkfs -t xfs /dev/sda12 failed with this concise message: "mkfs.xfs: cannot reserve space [28 - No space left on device]". (I try to xfs_check which also failed with a lot of error messages. So mkfs actually failled). May be have you some idea of some starting point of investigation? Thanks in advance for all, Joel From owner-linux-xfs@oss.sgi.com Thu Oct 24 02:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 02:13:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9O9DluR029981 for ; Thu, 24 Oct 2002 02:13:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9O9Dlpg029977 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 02:13:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9O9DiuV029955 for ; Thu, 24 Oct 2002 02:13:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9O8w17J029098; Thu, 24 Oct 2002 01:58:01 -0700 Date: Thu, 24 Oct 2002 01:58:01 -0700 Message-Id: <200210240858.g9O8w17J029098@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From juri@koschikode.com 2002-10-24 01:58 ------- Ok, thanks Eric. I think I'll go with a new cvs-kernel and see if it happens again. *If* it does I'll open a new bug. Until then I'm back to a known stable version (2.4.19-pre2-xfs ;) Juri ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 24 02:30:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 02:30:33 -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 g9O9UTuR031305 for ; Thu, 24 Oct 2002 02:30:30 -0700 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9F4E4AC47; Thu, 24 Oct 2002 11:25:25 +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 419FF190C6; Thu, 24 Oct 2002 11:25:24 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 34F5830881D; Thu, 24 Oct 2002 11:30:31 +0200 (CEST) Message-ID: <3DB7BDB6.680984F@ch.sauter-bc.com> Date: Thu, 24 Oct 2002 11:30:30 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.2pre2 available References: <1035411747.1231.7.camel@rose.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1227 X-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 Russell Cattelan schrieb: > > Well actually it's been there since Friday but not all the rpm's were > built. > > Thanks to Christoph the RH rpm's are not based off of the 2.4.18-17 > build from RedHat. Just to stop my own confusion: The source RPM of the RedHat 7.x and 8.0 kernel RPMs are exactly the same, only the release version differs. Of course, build environment is very different between 7.x and 8.0, so binaries are different. My question: Since used compiler versions were 'non standard' with older XFS releases, are there any issued when compiling the source RPM on RedHat 7.x, because it's targeted at 8.0, I guess. Or is it meant to work on 7.x and 8.0? Simon > > Here it the change log since 1.2 pre1 > > Changes in 1.2-pre2: > > * Backport faster 8-byte swap from 2.5 > > * Prevent blocks from being put on XFS's "busy list" twice. > > * Rearrange how xfs deals with read-only mounts vs. read-only devices. > 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. > Remove the vfs read-only checks for various xfs operations, > just check whether the underlying device is read-only > > * 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. > > * fix alloc busy list off by one errors, and simplify the bounds > check code. > > * 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. From owner-linux-xfs@oss.sgi.com Thu Oct 24 03:08:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 03:08:40 -0700 (PDT) Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OA8auR003264 for ; Thu, 24 Oct 2002 03:08:37 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g9OA8ft27132 for ; Thu, 24 Oct 2002 12:08:41 +0200 Received: from alg-ru-ext.tecosim.com(195.135.152.146), claiming to be "alg-ru.tecosim.de" via SMTP by dmz.tecosim.com, id smtpdvqy5pz; Thu Oct 24 12:08:39 2002 Received: from ns.tecosim.de (unknown [194.24.222.9]) by alg-ru.tecosim.de (Postfix) with ESMTP id 2461B18015 for ; Thu, 24 Oct 2002 12:08:39 +0200 (CEST) Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.6/8.11.6) with ESMTP id g9OA8cI09039 for ; Thu, 24 Oct 2002 12:08:38 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) id g9OA8c707929 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 12:08:38 +0200 Date: Thu, 24 Oct 2002 12:08:38 +0200 From: Utz Lehmann To: linux-xfs@oss.sgi.com Subject: Is ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ unmaintained? Message-ID: <20021024120838.E7403@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ulehmann@de.tecosim.com Precedence: bulk X-list: linux-xfs Hi A small question. Is ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ unmaintained? I only find the xfsdump-2.2.2 rpm in the 1.2 pre release path. utz From owner-linux-xfs@oss.sgi.com Thu Oct 24 04:06:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 04:06:21 -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 g9OB6HuR009566 for ; Thu, 24 Oct 2002 04:06:18 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184fop-00035r-00; Thu, 24 Oct 2002 12:06:27 +0100 Date: Thu, 24 Oct 2002 12:06:27 +0100 From: Christoph Hellwig To: Simon Matter Cc: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: XFS 1.2pre2 available Message-ID: <20021024120626.A11816@infradead.org> References: <1035411747.1231.7.camel@rose.americas.sgi.com> <3DB7BDB6.680984F@ch.sauter-bc.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: <3DB7BDB6.680984F@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Thu, Oct 24, 2002 at 11:30:30AM +0200 X-archive-position: 1229 X-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 24, 2002 at 11:30:30AM +0200, Simon Matter wrote: > Russell Cattelan schrieb: > > > > Well actually it's been there since Friday but not all the rpm's were > > built. > > > > Thanks to Christoph the RH rpm's are not based off of the 2.4.18-17 > > build from RedHat. > > Just to stop my own confusion: The source RPM of the RedHat 7.x and 8.0 > kernel RPMs are exactly the same, only the release version differs. Of > course, build environment is very different between 7.x and 8.0, so > binaries are different. > > My question: Since used compiler versions were 'non standard' with older > XFS releases, are there any issued when compiling the source RPM on > RedHat 7.x, because it's targeted at 8.0, I guess. Or is it meant to > work on 7.x and 8.0? I got an internal compiler error when compiling recent xfs versions with the original gcc of rh 7.3, I guess it's fixed with the latest errata. The gcc 3.2-compiled rpm works fine with rh7.x - it's just not self-hosted in that case. From owner-linux-xfs@oss.sgi.com Thu Oct 24 04:07:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 04:07:28 -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 g9OB7PuR009793 for ; Thu, 24 Oct 2002 04:07:25 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184fpv-000369-00; Thu, 24 Oct 2002 12:07:35 +0100 Date: Thu, 24 Oct 2002 12:07:35 +0100 From: Christoph Hellwig To: jsoe0708@tiscali.be Cc: linux-xfs@oss.sgi.com, Stephen Lord Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa Message-ID: <20021024120735.B11816@infradead.org> References: <3DA3C54C00002AA5@ocpmta5.be.tiscali.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: <3DA3C54C00002AA5@ocpmta5.be.tiscali.com>; from jsoe0708@tiscali.be on Thu, Oct 24, 2002 at 08:09:53AM +0200 X-archive-position: 1230 X-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 24, 2002 at 08:09:53AM +0200, jsoe0708@tiscali.be wrote: > Hi all, > > I build a xfs-kernel (20021022) diff versus 2.4.19 vanilla kernel, > apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable > (and operational) kernel. > > Now I rebuild debian package of xfsprogs-2.3.5 (cvs form) and obtain tools > binaries (without any warning or error) but even mkfs -t xfs /dev/sda12 failed > with this concise message: "mkfs.xfs: cannot reserve space [28 - No space > left on device]". > (I try to xfs_check which also failed with a lot of error messages. So mkfs > actually failled). > > May be have you some idea of some starting point of investigation? > > Thanks in advance for all, Can you send me the strace output for strace mkfs.xfs /dev/sda12? From owner-linux-xfs@oss.sgi.com Thu Oct 24 05:08:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 05:08:25 -0700 (PDT) Received: from localhost.localdomain (user-0ccsu93.cable.mindspring.com [24.206.121.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OC8MuR014268 for ; Thu, 24 Oct 2002 05:08:23 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id g9OC9Tgi031503; Thu, 24 Oct 2002 07:09:29 -0500 Received: (from ctooley@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id g9OC9S0h031501; Thu, 24 Oct 2002 07:09:28 -0500 X-Authentication-Warning: localhost.localdomain: ctooley set sender to ctooley@amoa.org using -f Subject: Re: RedHat 8.0 Installer From: Chris Tooley To: doug@simflex.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3413.206.153.21.5.1035412914.squirrel@mail.ccdmerchandise.com> References: <3413.206.153.21.5.1035412914.squirrel@mail.ccdmerchandise.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 07:09:28 -0500 Message-Id: <1035461368.31416.16.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 1231 X-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've used the 1.2pre1 installer a few times and just worked around the flukes. On that same note, there's no way I'd use it to install a box that I care about. This has nothing to do with the installer though. RedHat is a major version change. More major than the last few major version changes too. It breaks compatibility with more than just a few things. For instance, many perl modules from CPAN won't compile on the new threaded version of Perl 5.8. Apache 2 is used meaning that many webserver configurations have to be re-worked. Gnome2 is used meaning that much of the desktop does not work. Depending on your application there are a lot of things that will work, but just be forewarned that RedHat really went out on a limb to push the new technology. Before there are any major flames going on here, I firmly commend RedHat for this release, it was a major step to ensure that future releases didn't have to be dumbed down. The only way any of these major version differences were going to be overcome was to force the developers to update their packages and RedHat has a lot of influence on things like that (look at the number of RedHat 8 comments on here versus the number of Suse 8.1, also a fine distribution). However much I like the fact that this is happening, that doesn't help perl modules compile. The real answer is to either stick to RedHat 7.3 (which I'll be doing for quite a while) or be sure to thoroughly, thoroughly, thoroughly test your RedHat 8 installation first. In the end, the installer has some caveats, it does work, and I've used it several times. Chris Tooley P.S. Despite missing a lot of functionality that 1.4 has, the RedHat Gnome 2 installation is just absolutely beautiful to look at. On Wed, 2002-10-23 at 17:41, Doug Eubanks wrote: > > Is anyone using the Release-1.2pre1 RedHat Installer in production? I > have been using the installers for quite a while now and I need to redo a > server (that gets quite a bit of load) and I HATE EXT3. I was hoping to > get some feedback from someone who has used this version with RH8 > > Thanks, > > Sincerely, > Doug Eubanks > doug@simflex.com > > > ----------------------------------------- > This email was sent from ccdmerchandise.com. > It has been certified virus free! > Visit us online at http://www.ccdmerchandise.com > > > From owner-linux-xfs@oss.sgi.com Thu Oct 24 05:26:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 05:26:49 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OCQluR015826 for ; Thu, 24 Oct 2002 05:26:47 -0700 Subject: RE: Share suddenly empty Date: Thu, 24 Oct 2002 08:26:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5A2E4FE5C3D6544D94403072129E30D903A167@cli_exch_one.complexlit.com> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: Share suddenly empty Thread-Index: AcJ6208cqmks0UPRRAa844JJl1Cu4QAeswUg From: "Brian Gulizia" To: "Seth Mos" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OCQluR015830 X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Unfortunately...... I couldnt check the /var/log/messages since its turned off. I had to turn it off due to the other problem I've been having. (see article with subject aic7xxx parity error detected in data-in phase) I was also curious if these two issues were related..... I've already started an xfs_repair with the assume_xfs option...started it yesterday at about 4pm....its still running....heh. But then it is about 360gbs *crosses fingers* brian -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Wednesday, October 23, 2002 5:30 PM To: Brian Gulizia Cc: linux-xfs@oss.sgi.com Subject: RE: Share suddenly empty On Wed, 23 Oct 2002, Brian Gulizia wrote: > I hadnt done anything to it. All I did was reboot, I got the "not a valid block > device" when i tried to mout it, rebooted again and was able to mount it but it has > nothing on it when I do an ls. You'll have to excuse my newbieness, but when you > say let the filesystem do recovery, what do you mean? I didnt see anything about the > kernel doing any recovering. The recovery part is something the filesystem does after a "unclean unmount" eg. poweroff. When you mount the filesystem it would be done automatically. If recovery was required there will be a message during the mount of the filesystem. And if I am right there should at least be a message in you /var/log/messages (or equivalent) stating that there was a filesystem error. If not from the just attempted mount there should at least be one from when the files first "dissappeard". Did you already repair the filesystem per chance? Check with mount if it is unmounted. xfs_repair -n /dev/sdb? or xfs_check /dev/sdb? and check for errors or other problems it finds. Mail that back to the list (zipped please). If there is nothing serious in there you could attempt a repair of the filesystem if you are couragesous ;-) I'm going to bed here, maybe someone from america can pick this up *hint* See you in 8 hours. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Oct 24 05:34:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 05:34:04 -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 g9OCY2uR016654 for ; Thu, 24 Oct 2002 05:34:02 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA30981; Thu, 24 Oct 2002 07:34:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA54062; Thu, 24 Oct 2002 07:34:08 -0500 (CDT) Date: Thu, 24 Oct 2002 07:30:10 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@jen.americas.sgi.com To: Utz Lehmann cc: linux-xfs@oss.sgi.com Subject: Re: Is ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ unmaintained? In-Reply-To: <20021024120838.E7403@de.tecosim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1233 X-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 It's maintained, but it's essentially a snapshot dir, manually updated. I promised to get it up to date yesterday, but ran into other things. I'll see if I can get scripted builds & updates going sometime soon. -Eric On Thu, 24 Oct 2002, Utz Lehmann wrote: > Hi > > A small question. Is ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/ > unmaintained? I only find the xfsdump-2.2.2 rpm in the 1.2 pre release path. > > > utz > > From owner-linux-xfs@oss.sgi.com Thu Oct 24 07:43:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 07:43:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9OEhkuR032676 for ; Thu, 24 Oct 2002 07:43:46 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9OEhk7s032675 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 07:43:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9OEhiuT032661 for ; Thu, 24 Oct 2002 07:43:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9OEasGv032226; Thu, 24 Oct 2002 07:36:54 -0700 Date: Thu, 24 Oct 2002 07:36:54 -0700 Message-Id: <200210241436.g9OEasGv032226@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 187] New: XFS memory corruption X-Bugzilla-Reason: AssignedTo X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=187 Summary: XFS memory corruption Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: waitt@saic.com What kernel are you using: 2.4.19 stock plus 2.4.19 XFS full patchset from SGI website Running rh7.3, XFS volume is on a Dell Powervault with LSI Logic MegaRAID 1.57 Description of Problem: I ran XFS 1.0 and 1.1 without any problems for 18 months. After upgrading to rh7.3 and 2.4.19, within 24 hrs I got this: Oct 24 05:05:22 wolf kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xc020bca8 Oct 24 05:05:22 wolf kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Oct 24 05:05:22 wolf kernel: Please umount the filesystem, and rectify the problem(s) I have no idea how to replicate this, and I'm not sure I want to ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 24 08:11:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 08:12: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 g9OFBwuR002994 for ; Thu, 24 Oct 2002 08:11:58 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) 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 IAA01026 for ; Thu, 24 Oct 2002 08:12:10 -0700 (PDT) mail_from (alkirkco@sgi.com) Received: from sgi.com (syntegra.americas.sgi.com [128.162.191.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g9OFB9px27646263 for ; Thu, 24 Oct 2002 08:11:09 -0700 (PDT) Message-ID: <3DB80D8D.4020201@sgi.com> Date: Thu, 24 Oct 2002 10:11:09 -0500 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE 871460 - xfsdump -I core dump when one of the inventory/*StObj was corrupted] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs -------- Original Message -------- Subject: UPDATE 871460 - TAKE - xfsdump -I core dump when one of the inventory/*StObj was corrupted Date: Thu, 24 Oct 2002 07:53:08 -0700 (PDT) From: pv@relay.sgi.com (alkirkco@sgi.com) Reply-To: sgi.bugs.snlinux@fido.engr.sgi.com To: alkirkco@sgi.com CC: sgi.bugs.xfs@sgi.com, sgilinux1-triage@sgi.com View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=871460 *CC List : sgi.bugs.xfs@sgi.com Status : closed *Priority : 3 Assigned Engineer : alkirkco Submitter : alkirkco *Classification : bug Opened Date : 10/24/02 *Category : software *Modified User : alkirkco *Modified User Domain : sgi.com *Description : ========================== ADDITIONAL INFORMATION (UPDATE) From: alkirkco@sgi.com (BugWorks) Date: Oct 24 2002 07:53:07AM ========================== ACTIONS: Classification: mod -> bug Priority: 4 -> 3 -------------------------- This fix is for a bug reported in IRIX xfsdump in PV 855537. The fix was checked into IRIX 6.5.19 m&f earlier today. The same fix has just been checked into the Linux slinx tree as modid xfs-cmds:slinx:130979a. Targets: -------- sbin/xfsdump sbin/xfsrestore Source files affected: ---------------------- eoe/cmd/xfs/dump/inventory/inv_stobj.c Code Diff: ================================================================================ eoe/cmd/xfs/dump/inventory/inv_stobj.c ================================================================================ barney 65% p_rdiff -u inv_stobj.c --- /usr/tmp/TmpDir.22172-0/cmd/xfsdump/inventory/inv_stobj.c_1.7 Thu Oct 24 09:20:27 2002 +++ cmd/xfsdump/inventory/inv_stobj.c Thu Oct 24 09:20:02 2002 @@ -1264,9 +1264,15 @@ } /* copy the mediafile into the exported structure */ - stobj_convert_mfile( &ises->s_streams[i].st_mediafiles[j], - &mf); - + if (ises->s_streams[i].st_mediafiles) { + stobj_convert_mfile( &ises->s_streams[i].st_mediafiles[j], + &mf); + } else { + mlog(MLOG_ERROR, "Failed to get data from media file: " + "possible file corruption\n"); + mlog_exit_hint(RV_CORRUPT); + return -1; + } } } From owner-linux-xfs@oss.sgi.com Thu Oct 24 08:13:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 08:13:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9OFDjuR003909 for ; Thu, 24 Oct 2002 08:13:45 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9OFDjeh003908 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 08:13:45 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9OFDiuT003893 for ; Thu, 24 Oct 2002 08:13:44 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9OEpwvm001560; Thu, 24 Oct 2002 07:51:58 -0700 Date: Thu, 24 Oct 2002 07:51:58 -0700 Message-Id: <200210241451.g9OEpwvm001560@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 187] XFS memory corruption X-Bugzilla-Reason: AssignedTo X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=187 ------- Additional Comments From sandeen@sgi.com 2002-10-24 07:51 ------- This one probably means that a dirty transaction was canceled. I've seen this force shutdown before, but I don't know where it may be coming from, and it does seem hard to reproduce. Thanks for opening the bug, it's definitely one we need to track. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 24 08:19:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 08:19:36 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OFJYuR005629 for ; Thu, 24 Oct 2002 08:19:34 -0700 Subject: RE: aic7xxx pairty error detected in data-in phase Date: Thu, 24 Oct 2002 11:19:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5A2E4FE5C3D6544D94403072129E30D92B891C@cli_exch_one.complexlit.com> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: aic7xxx pairty error detected in data-in phase Thread-Index: AcJ6AA+A0TUZvn+UT0+m4fGoyY/M9wBcJ9wg From: "Brian Gulizia" To: "Eric Sandeen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OFJZuR005639 X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Is there a card that I could replace the 39160 that SGI's XFS is happier with? We can always recycle the 39160 into another machine. Brian -----Original Message----- From: Eric Sandeen [mailto:sandeen@SGI.com] Sent: Tuesday, October 22, 2002 10:48 AM To: Brian Gulizia Cc: linux-xfs@oss.sgi.com Subject: Re: aic7xxx pairty error detected in data-in phase You might try the 2.4.18-14 kernel available in the XFS 1.2 prerelease, although this will be changing much more than just your scsi driver. A 2.4.18-17 kernel with xfs merged will probably be available from us in the not-so-distant future. -Eric On Tue, 2002-10-22 at 07:54, Brian Gulizia wrote: > Hi all, > > First, let me apologize if this has been addressed. > > I am currently running a Dell 1650 witth Redhat 7.3 & SGI's XFS 1.1. The Kernel is 2.4.18-4SGI_XFS_1.1smp. I have an adaptec 39160 card installed with 2 Maxtronic Arena Raid boxes attached, 1 to each channel (arena raid box is simply 14 IDE hard drives connected to a scsi backplane). > > I am receiving the following error in my messages log 4 times every second, filling up my var rapidly: > > ******** > (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x4e) SCSIRATE(0xc2) > No terminal CRC packet received. > ********* > > I've been through the archives of this list, as well as having done searches on groups.google.com and have tried all of the suggestions mentioned. I have replaced the cable and I changed the memory out on the scsi card inside the raid box. The next step I was going to try was replacing the 39160 card, but found out there was a new aic7xxx driver available, as well as a new kernel rpm. As I am a relative Linux newbie, I spoke with Dell and they told me to load the new kernel, kernel-smp-2.4.18-17.7.x.i686.rpm. The problem is that this kernel does not support xfs, but it did in fact stop the message from occuring. We then tried to integrate the new aic7xxx driver into the xfs kernel with no luck. > Has anyone else run into this problem? Do you have any suggestions? Was I doing something wrong? > Thanks, > Brian Gulizia > > > [[HTML alternate version deleted]] > -- 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 Thu Oct 24 09:15:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 09:15: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 g9OGFWuR009704 for ; Thu, 24 Oct 2002 09:15:32 -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 LAA06102 for ; Thu, 24 Oct 2002 11:15:39 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA04684 for ; Thu, 24 Oct 2002 11:15:38 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g9ONUdM01581 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 19:30:39 -0400 Resent-Message-Id: <200210242330.g9ONUdM01581@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA71104 for ; Thu, 24 Oct 2002 11:10:58 -0500 (CDT) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g9OGAupx26842744 for ; Thu, 24 Oct 2002 09:10:57 -0700 (PDT) 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 g9OG9riJ001085 for ; Thu, 24 Oct 2002 18:09:53 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9OG9rdW001084 for hch@sgi.com; Thu, 24 Oct 2002 18:09:53 +0200 Date: Thu, 24 Oct 2002 18:09:53 +0200 Message-Id: <200210241609.g9OG9rdW001084@lab343.munich.sgi.com> Subject: TAKE - don't call run_task_queue(&tq_disk) with spinlock held To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 24 Oct 2002 19:30:39 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1238 X-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@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Oct 24 09:09:39 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:130991a linux/fs/xfs/pagebuf/page_buf.c - 1.72 From owner-linux-xfs@oss.sgi.com Thu Oct 24 09:45:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 09:45:54 -0700 (PDT) Received: from intranet.mtp.eprocess.fr (mail.eprocess.fr [62.23.135.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OGjluR012271 for ; Thu, 24 Oct 2002 09:45:48 -0700 Received: from eprocess.fr (fcombernous.mtp.eprocess.fr [192.168.2.14]) by intranet.mtp.eprocess.fr (8.9.3/8.9.3) with ESMTP id SAA28032; Thu, 24 Oct 2002 18:45:20 +0200 Message-ID: <3DB823AA.6010405@eprocess.fr> Date: Thu, 24 Oct 2002 18:45:30 +0200 From: Fabien Combernous User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 X-Accept-Language: en MIME-Version: 1.0 To: ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com Subject: To compare Linux journalised filesystem, part II. Content-Type: multipart/mixed; boundary="------------050600050304080100000904" X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fcombernous@eprocess.fr Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------050600050304080100000904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by intranet.mtp.eprocess.fr id SAA28032 Back, After to get all informations i received, i put them in table as follow: see attachment file. Specialists can they tell me if they agree with my conclusions ? Thank's for your good job. Fabien. --=20 Fabien COMBERNOUS - IT Engineer eProcess - Parc Club du Mill=E9naire Batiment n=B0 6 1025 rue Henri Becquerel - 34000 Montpellier FRANCE http://www.eprocess.fr - +33 (0)4 67 13 84 50 --------------050600050304080100000904 Content-Type: text/plain; name="features" Content-Disposition: inline; filename="features" Content-Transfer-Encoding: 7bit +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | Features \ fs | xfs | ext3 | jfs | reiserfs | Comments | +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | mmutable | N | Y | Y | Y | "Y" is not with same sens. Implementation is not same. Each one permit | | append-only | | | | | some elements that other don't permit and reverse. xfs will have | | | | | | | implementation in futur. | +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | quotas | Y | Y | Y | Y | Again "Y" is not aqual. ext3 accept quota only on data-journaled | | | | | | | filesystems, but all other journaled filesystem don't have data journal| | | | | | | About reiserfs you need Chris patches. +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | NFS | Y | Y | Y | Y | nfs works on all of them. You need at least reiserfs v3.6. +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | samba | Y | Y | Y | Y | Since Samba is userspace, the fs shouldn't matter (2.2.4 or 2.2.5) | +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ | coda | coda is a file sys him self | / / / / | +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ |data journal | N | Y | N | N | Only ext3 can take care of data by a data journal. All other journaled | | | | | | | file systems have "only" a metadata journal. | +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ --------------050600050304080100000904-- From owner-linux-xfs@oss.sgi.com Thu Oct 24 09:54:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 09:54:29 -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 g9OGsNuR013172 for ; Thu, 24 Oct 2002 09:54:23 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 184lFb-0005zh-00; Thu, 24 Oct 2002 17:54:27 +0100 Date: Thu, 24 Oct 2002 17:54:27 +0100 From: Christoph Hellwig To: Fabien Combernous Cc: ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com Subject: Re: [Jfs-discussion] To compare Linux journalised filesystem, part II. Message-ID: <20021024175427.A23034@infradead.org> References: <3DB823AA.6010405@eprocess.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DB823AA.6010405@eprocess.fr>; from fcombernous@eprocess.fr on Thu, Oct 24, 2002 at 06:45:30PM +0200 X-archive-position: 1240 X-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 24, 2002 at 06:45:30PM +0200, Fabien Combernous wrote: > | mmutable | N | Y | Y | Y | "Y" is not with same sens. Implementation is not same. Each one permit | > | append-only | | | | | some elements that other don't permit and reverse. xfs will have | > | | | | | | implementation in futur. | neither jfs or reiserfs support this.. > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | quotas | Y | Y | Y | Y | Again "Y" is not aqual. ext3 accept quota only on data-journaled | > | | | | | | filesystems, but all other journaled filesystem don't have data journal| > | | | | | | About reiserfs you need Chris patches. jfs doesn't support quotas. From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:05:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:05:49 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OH5huR014549 for ; Thu, 24 Oct 2002 10:05:43 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9OH55aF023088; Thu, 24 Oct 2002 12:05:06 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9OH44eO023081; Thu, 24 Oct 2002 12:04:04 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Re: Qlogic 2300 and XFS From: Austin Gonyou To: Martin Spott Cc: linux-xfs In-Reply-To: <200210192057.WAA05071@sirius.quickstep.oche.de> References: <200210192057.WAA05071@sirius.quickstep.oche.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 12:03:04 -0500 Message-Id: <1035478984.22917.2.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1241 X-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 Sat, 2002-10-19 at 15:57, Martin Spott wrote: > > Anyone here using Qlogic 2300Fs and XFS with an uptime of > 30 days on > > 5.38.x drivers or > 15 days on 6.0x drivers? > > I've experienced _numerous_ crashes on SMP machines (ASUS CUR-DLS) after > _very_ few days uptime with QLA2300. I've used the drivers included in > kernel 2.4.18 (with xfs-1.1) and 2.4.14 without XFS. The crashes > disappeared > after disabling one CPU. I never experienced these crashes with QLA2200 > .... > > What are you aiming at ? I've had some problems using 2.4.19-aa1 + XFS + LVM + QLogic 2300's and 6.01 drivers. Removing LVM from the mix has, so far, kept us sane. I'm trying to scare up any information I can, because the we have a 2300 on a Dell 4400, which has all slots full, and using the 6.01 driver, crashes the box so FAST and in the middle of an IO operation, that I can't debug it. I'm trying to figure out if it's a 2300 PCIX problem, or if it's just crappy drivers. > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are > ! > ------------------------------------------------------------------------ > -- > From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:07:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:07:45 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OH7huR015112 for ; Thu, 24 Oct 2002 10:07:43 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9OH77aF023093; Thu, 24 Oct 2002 12:07:07 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9OH66aL023091; Thu, 24 Oct 2002 12:06:06 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Re: [Bug 185] New: Mount by LABEL does not work on whole disks. From: Austin Gonyou To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021019173648.A314255@wobbly.melbourne.sgi.com> References: <20021019173648.A314255@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 12:03:34 -0500 Message-Id: <1035479106.23083.3.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1242 X-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 Sat, 2002-10-19 at 02:36, Nathan Scott wrote: > On Fri, Oct 18, 2002 at 11:30:51PM -0500, Austin Gonyou wrote: > > ... > > Understood. I thought you told me to submit it as a bug for XFS > though? > > Did I misunderstand? > > > > Yeah, I should have been clearer - Andries wanted someone to send > him a bug report saying why this is needed (seems obvious to me, > but I think thats what he was after). Ahhh..OK. THanks :) > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:10:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:10:59 -0700 (PDT) Received: from webber.adilger.int (h68-147-110-38.cg.shawcable.net [68.147.110.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OHAvuR015748 for ; Thu, 24 Oct 2002 10:10:57 -0700 Received: from webber.adilger.int (adilger@localhost [127.0.0.1]) by webber.adilger.int (8.12.6/8.12.6/Debian-5) with ESMTP id g9OH8TWk022277 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Oct 2002 11:08:30 -0600 Received: (from adilger@localhost) by webber.adilger.int (8.12.6/8.12.6/Debian-5) id g9OH8RkZ022275; Thu, 24 Oct 2002 11:08:27 -0600 From: Andreas Dilger Date: Thu, 24 Oct 2002 11:08:26 -0600 To: Fabien Combernous Cc: ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com Subject: Re: [ext3-users] To compare Linux journalised filesystem, part II. Message-ID: <20021024170826.GI28822@clusterfs.com> Mail-Followup-To: Fabien Combernous , ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com References: <3DB823AA.6010405@eprocess.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB823AA.6010405@eprocess.fr> User-Agent: Mutt/1.4i X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: adilger@clusterfs.com Precedence: bulk X-list: linux-xfs On Oct 24, 2002 18:45 +0200, Fabien Combernous wrote: > +--------+------------------------------------------------------------------+ > | quotas | Again "Y" is not aqual. ext3 accept quota only on data-journaled | > | | filesystems, but all other journaled filesystem don't have data | > +--------+------------------------------------------------------------------+ Granted that I have never used quotas, so it is possible that I am incorrect. However, my understanding is that yes, you do need data-journaled quota files to ensure that your quota tables don't miss some operations after a crash. However, you can separately select data journaling for files in ext3 (via chattr), even if the rest of the filesystem is using data=ordered (the default). Cheers, Andreas -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/ From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:27:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:27:04 -0700 (PDT) Received: from tiny.suse.com (216-42-72-147.ppp.netsville.net [216.42.72.147]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OHQwuR019198 for ; Thu, 24 Oct 2002 10:26:59 -0700 Received: from localhost ([127.0.0.1]) by tiny.suse.com with esmtp (Exim 4.10) id 184llb-0003Xz-00; Thu, 24 Oct 2002 13:27:31 -0400 Subject: Re: [reiserfs-list] Re: [ext3-users] To compare Linux journalised filesystem, part II. From: Chris Mason To: Andreas Dilger Cc: Fabien Combernous , ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com In-Reply-To: <20021024170826.GI28822@clusterfs.com> References: <3DB823AA.6010405@eprocess.fr> <20021024170826.GI28822@clusterfs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Oct 2002 13:27:31 -0400 Message-Id: <1035480451.30133.192.camel@tiny> Mime-Version: 1.0 X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mason@suse.com Precedence: bulk X-list: linux-xfs On Thu, 2002-10-24 at 13:08, Andreas Dilger wrote: > On Oct 24, 2002 18:45 +0200, Fabien Combernous wrote: > > +--------+------------------------------------------------------------------+ > > | quotas | Again "Y" is not aqual. ext3 accept quota only on data-journaled | > > | | filesystems, but all other journaled filesystem don't have data | > > +--------+------------------------------------------------------------------+ > > Granted that I have never used quotas, so it is possible that I > am incorrect. However, my understanding is that yes, you do need > data-journaled quota files to ensure that your quota tables don't miss > some operations after a crash. However, you can separately select > data journaling for files in ext3 (via chattr), even if the rest of > the filesystem is using data=ordered (the default). data journaling on the quota files is better. Some quota updates (dqput calling commit_dquot) are done only by clear_inode(), which should happen outside the transaction and won't be grouped with the actual metadata change. -chris From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:37:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:37:38 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm3.tiscalinet.be [212.35.2.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OHbQuR022936 for ; Thu, 24 Oct 2002 10:37:27 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscali) id 184lvL-0005HA-00; Thu, 24 Oct 2002 19:37:35 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Thu, 24 Oct 2002 19:37:33 +0200 Date: Thu, 24 Oct 2002 19:37:33 +0200 Message-ID: <3DB03B6D0000037E@ocpmta6.be.tiscali.com> In-Reply-To: <20021024120735.B11816@infradead.org> From: jsoe0708@tiscali.be Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa To: "Christoph Hellwig" Cc: linux-xfs@oss.sgi.com, "Stephen Lord" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=========3DB03B6D0000037E/mail.tiscali.be" X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs --=========3DB03B6D0000037E/mail.tiscali.be Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Christoph, > >Can you send me the strace output for strace mkfs.xfs /dev/sda12? > Here you are: execve("/sbin/mkfs.xfs", ["mkfs.xfs", "/dev/sda12"], [/* 15 vars */]) = 0 newuname({sys="Linux", node="palinux", ...}) = 0 brk(0) = 0x60000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 22508, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2\37"..., 1024) = 1024 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 1392404, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000 mprotect(0x4015f000, 118548, PROT_NONE) = 0 mmap(0x4016e000, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x136000) = 0x4016e000 mmap(0x40179000, 12052, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40179000 close(3) = 0 munmap(0x40018000, 22508) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 brk(0) = 0x60000 brk(0x601b0) = 0x601b0 brk(0x61000) = 0x61000 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 read(3, "", 1024) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 read(3, "", 1024) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 getcwd("/root", 4096) = 6 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 ustat(0x80c, 0xfaf01bd0) = -1 EINVAL (Invalid argument) open("/dev/sda12", O_RDONLY|O_LARGEFILE) = 3 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 ustat(0x80c, 0xfaf01bd0) = -1 EINVAL (Invalid argument) open("/dev/sda12", O_RDWR|O_LARGEFILE) = 4 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 ioctl(4, 0x80041271, 0xfaf01c40) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 open("/dev/sda12", O_RDONLY|O_LARGEFILE) = 5 ioctl(5, 0x40041272, 0xfaf01c40) = 0 close(5) = 0 chdir("/root") = 0 close(3) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 open("/dev/sda12", O_RDONLY|O_LARGEFILE) = 3 _llseek(0x3, 0, 0, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 576) = 576 _llseek(0x3, 0, 0x200, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 _llseek(0x3, 0, 0x400, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 228) = 228 _llseek(0x3, 0, 0x400, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24) = 24 _llseek(0x3, 0, 0xc00, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 _llseek(0x3, 0, 0x2000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1376) = 1376 _llseek(0x3, 0, 0x2000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 _llseek(0x3, 0, 0x2000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0", 8) = 8 _llseek(0x3, 0, 0x8000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 168) = 168 _llseek(0x3, 0, 0x8000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048 _llseek(0x3, 0, 0x10000, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 _llseek(0x3, 0, 0, 0xfaf0a148, 0) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 close(3) = 0 open("/dev/sda12", O_RDONLY|O_LARGEFILE) = 3 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 close(3) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 access("/proc/mounts", R_OK) = 0 open("/etc/mtab", O_RDONLY) = 3 brk(0x63000) = 0x63000 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "/dev/md0 / ext3 rw,errors=remoun"..., 4096) = 337 stat64("/dev/md0", {st_mode=0, st_size=6, ...}) = 0 stat64("proc", 0xfaf00b00) = -1 ENOENT (No such file or directory) stat64("devpts", 0xfaf00b00) = -1 ENOENT (No such file or directory) stat64("/dev/sdb3", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md2", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md3", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md4", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md5", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md6", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/md7", {st_mode=0, st_size=6, ...}) = 0 stat64("/dev/sdd1", {st_mode=0, st_size=6, ...}) = 0 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 stat64("/dev/sda12", {st_mode=0, st_size=6, ...}) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 read(3, "", 1024) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "Character devices:\n 1 mem\n 2 p"..., 1024) = 225 read(3, "", 1024) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 gettimeofday({1035482269, 103368}, NULL) = 0 open("/dev/urandom", O_RDONLY) = 3 getpid() = 312 getuid() = 0 gettimeofday({1035482269, 109910}, NULL) = 0 gettimeofday({1035482269, 111662}, NULL) = 0 read(3, "\207\210\4\343\211\10\362\200\20\227Q\357\247\214\337\266"..., 16) = 16 brk(0x75000) = 0x75000 pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 69632, 0) = 69632 pwrite(4, "XFSB\0\0\20\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512, 0) = 512 fstat64(1, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536, 2199023190016) = -1 ENOSPC (No space left on device) write(2, "mkfs.xfs: write failed: No space"..., 48mkfs.xfs: write failed: No space left on device ) = 48 write(1, "meta-data=/dev/sda12 "..., 457meta-data=/dev/sda12 isize=256 agcount=512, agsize=1048576 blks data = bsize=4096 blocks=536870912, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ) = 457 munmap(0x40018000, 4096) = 0 exit(1) = ? Hth (me no), Joel --=========3DB03B6D0000037E/mail.tiscali.be Content-Type: application/msword Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="StraceXfs.doc" ZXhlY3ZlKCIvc2Jpbi9ta2ZzLnhmcyIsIFsibWtmcy54ZnMiLCAiL2Rldi9z ZGExMiJdLCBbLyogMTUgdmFycyAqL10pID0gMApuZXd1bmFtZSh7c3lzPSJM aW51eCIsIG5vZGU9InBhbGludXgiLCAuLi59KSA9IDAKYnJrKDApICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHg2MDAwMAptbWFwKE5V TEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxN QVBfQU5PTllNT1VTLCAtMSwgMCkgPSAweDQwMDE3MDAwCm9wZW4oIi9ldGMv bGQuc28ucHJlbG9hZCIsIE9fUkRPTkxZKSAgICA9IC0xIEVOT0VOVCAoTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbigiL2V0Yy9sZC5zby5jYWNo ZSIsIE9fUkRPTkxZKSAgICAgID0gMwpmc3RhdDY0KDMsIHtzdF9tb2RlPTAs IHN0X3NpemU9MCwgLi4ufSkgPSAwCm1tYXAoTlVMTCwgMjI1MDgsIFBST1Rf UkVBRCwgTUFQX1BSSVZBVEUsIDMsIDApID0gMHg0MDAxODAwMApjbG9zZSgz KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwCm9wZW4oIi9s aWIvbGliYy5zby42IiwgT19SRE9OTFkpICAgICAgICA9IDMKcmVhZCgzLCAi XDE3N0VMRlwxXDJcMVwzXDBcMFwwXDBcMFwwXDBcMFwwXDNcMFwxN1wwXDBc MFwxXDBcMlwzNyIuLi4sIDEwMjQpID0gMTAyNApmc3RhdDY0KDMsIHtzdF9t b2RlPTAsIHN0X3NpemU9MCwgLi4ufSkgPSAwCm1tYXAoTlVMTCwgMTM5MjQw NCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEUsIDMsIDApID0g MHg0MDAyODAwMAptcHJvdGVjdCgweDQwMTVmMDAwLCAxMTg1NDgsIFBST1Rf Tk9ORSkgPSAwCm1tYXAoMHg0MDE2ZTAwMCwgNDUwNTYsIFBST1RfUkVBRHxQ Uk9UX1dSSVRFfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8TUFQX0ZJWEVELCAz LCAweDEzNjAwMCkgPSAweDQwMTZlMDAwCm1tYXAoMHg0MDE3OTAwMCwgMTIw NTIsIFBST1RfUkVBRHxQUk9UX1dSSVRFfFBST1RfRVhFQywgTUFQX1BSSVZB VEV8TUFQX0ZJWEVEfE1BUF9BTk9OWU1PVVMsIC0xLCAwKSA9IDB4NDAxNzkw MDAKY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0g MAptdW5tYXAoMHg0MDAxODAwMCwgMjI1MDgpICAgICAgICAgICAgICAgPSAw CnN0YXQ2NCgiL2Rldi9zZGExMiIsIHtzdF9tb2RlPTAsIHN0X3NpemU9Niwg Li4ufSkgPSAwCmJyaygwKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA9IDB4NjAwMDAKYnJrKDB4NjAxYjApICAgICAgICAgICAgICAgICAg ICAgICAgICAgID0gMHg2MDFiMApicmsoMHg2MTAwMCkgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPSAweDYxMDAwCm9wZW4oIi9wcm9jL2RldmljZXMi LCBPX1JET05MWXxPX0xBUkdFRklMRSkgPSAzCmZzdGF0NjQoMywge3N0X21v ZGU9MCwgc3Rfc2l6ZT0wLCAuLi59KSA9IDAKbW1hcChOVUxMLCA0MDk2LCBQ Uk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9V UywgLTEsIDApID0gMHg0MDAxODAwMApyZWFkKDMsICJDaGFyYWN0ZXIgZGV2 aWNlczpcbiAgMSBtZW1cbiAgMiBwIi4uLiwgMTAyNCkgPSAyMjUKY2xvc2Uo MykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMAptdW5tYXAo MHg0MDAxODAwMCwgNDA5NikgICAgICAgICAgICAgICAgPSAwCm9wZW4oIi9w cm9jL2RldmljZXMiLCBPX1JET05MWXxPX0xBUkdFRklMRSkgPSAzCmZzdGF0 NjQoMywge3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAuLi59KSA9IDAKbW1hcChO VUxMLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8 TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHg0MDAxODAwMApyZWFkKDMsICJD aGFyYWN0ZXIgZGV2aWNlczpcbiAgMSBtZW1cbiAgMiBwIi4uLiwgMTAyNCkg PSAyMjUKY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gMAptdW5tYXAoMHg0MDAxODAwMCwgNDA5NikgICAgICAgICAgICAgICAg PSAwCm9wZW4oIi9wcm9jL2RldmljZXMiLCBPX1JET05MWXxPX0xBUkdFRklM RSkgPSAzCmZzdGF0NjQoMywge3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAuLi59 KSA9IDAKbW1hcChOVUxMLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklURSwg TUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHg0MDAxODAw MApyZWFkKDMsICJDaGFyYWN0ZXIgZGV2aWNlczpcbiAgMSBtZW1cbiAgMiBw Ii4uLiwgMTAyNCkgPSAyMjUKcmVhZCgzLCAiIiwgMTAyNCkgICAgICAgICAg ICAgICAgICAgICAgID0gMApjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAwCm11bm1hcCgweDQwMDE4MDAwLCA0MDk2KSAgICAg ICAgICAgICAgICA9IDAKb3BlbigiL3Byb2MvZGV2aWNlcyIsIE9fUkRPTkxZ fE9fTEFSR0VGSUxFKSA9IDMKZnN0YXQ2NCgzLCB7c3RfbW9kZT0wLCBzdF9z aXplPTAsIC4uLn0pID0gMAptbWFwKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQ Uk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwgMCkg PSAweDQwMDE4MDAwCnJlYWQoMywgIkNoYXJhY3RlciBkZXZpY2VzOlxuICAx IG1lbVxuICAyIHAiLi4uLCAxMDI0KSA9IDIyNQpyZWFkKDMsICIiLCAxMDI0 KSAgICAgICAgICAgICAgICAgICAgICAgPSAwCmNsb3NlKDMpICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA9IDAKbXVubWFwKDB4NDAwMTgwMDAs IDQwOTYpICAgICAgICAgICAgICAgID0gMApnZXRjd2QoIi9yb290IiwgNDA5 NikgICAgICAgICAgICAgICAgICAgPSA2CnN0YXQ2NCgiL2Rldi9zZGExMiIs IHtzdF9tb2RlPTAsIHN0X3NpemU9NiwgLi4ufSkgPSAwCnN0YXQ2NCgiL2Rl di9zZGExMiIsIHtzdF9tb2RlPTAsIHN0X3NpemU9NiwgLi4ufSkgPSAwCnVz dGF0KDB4ODBjLCAweGZhZjAxYmQwKSAgICAgICAgICAgICAgICA9IC0xIEVJ TlZBTCAoSW52YWxpZCBhcmd1bWVudCkKb3BlbigiL2Rldi9zZGExMiIsIE9f UkRPTkxZfE9fTEFSR0VGSUxFKSA9IDMKc3RhdDY0KCIvZGV2L3NkYTEyIiwg e3N0X21vZGU9MCwgc3Rfc2l6ZT02LCAuLi59KSA9IDAKc3RhdDY0KCIvZGV2 L3NkYTEyIiwge3N0X21vZGU9MCwgc3Rfc2l6ZT02LCAuLi59KSA9IDAKdXN0 YXQoMHg4MGMsIDB4ZmFmMDFiZDApICAgICAgICAgICAgICAgID0gLTEgRUlO VkFMIChJbnZhbGlkIGFyZ3VtZW50KQpvcGVuKCIvZGV2L3NkYTEyIiwgT19S RFdSfE9fTEFSR0VGSUxFKSAgPSA0CnN0YXQ2NCgiL2Rldi9zZGExMiIsIHtz dF9tb2RlPTAsIHN0X3NpemU9NiwgLi4ufSkgPSAwCmlvY3RsKDQsIDB4ODAw NDEyNzEsIDB4ZmFmMDFjNDApICAgICAgICA9IDAKc3RhdDY0KCIvZGV2L3Nk YTEyIiwge3N0X21vZGU9MCwgc3Rfc2l6ZT02LCAuLi59KSA9IDAKb3Blbigi L2Rldi9zZGExMiIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFKSA9IDUKaW9jdGwo NSwgMHg0MDA0MTI3MiwgMHhmYWYwMWM0MCkgICAgICAgID0gMApjbG9zZSg1 KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwCmNoZGlyKCIv cm9vdCIpICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAKY2xvc2UoMykg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMApzdGF0NjQoIi9k ZXYvc2RhMTIiLCB7c3RfbW9kZT0wLCBzdF9zaXplPTYsIC4uLn0pID0gMApv cGVuKCIvZGV2L3NkYTEyIiwgT19SRE9OTFl8T19MQVJHRUZJTEUpID0gMwpf bGxzZWVrKDB4MywgMCwgMCwgMHhmYWYwYTE0OCwgMCkgICAgICAgPSAwCnJl YWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMCIuLi4sIDU3NikgPSA1NzYKX2xsc2VlaygweDMs IDAsIDB4MjAwLCAweGZhZjBhMTQ4LCAwKSAgID0gMApyZWFkKDMsICJcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDAiLi4uLCA1MTIpID0gNTEyCl9sbHNlZWsoMHgzLCAwLCAweDQwMCwg MHhmYWYwYTE0OCwgMCkgICA9IDAKcmVhZCgzLCAiXDBcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwg MjI4KSA9IDIyOApfbGxzZWVrKDB4MywgMCwgMHg0MDAsIDB4ZmFmMGExNDgs IDApICAgPSAwCnJlYWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIsIDI0KSA9IDI0Cl9sbHNlZWsoMHgz LCAwLCAweGMwMCwgMHhmYWYwYTE0OCwgMCkgICA9IDAKcmVhZCgzLCAiXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwIi4uLiwgNTEyKSA9IDUxMgpfbGxzZWVrKDB4MywgMCwgMHgyMDAw LCAweGZhZjBhMTQ4LCAwKSAgPSAwCnJlYWQoMywgIlwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4s IDEzNzYpID0gMTM3NgpfbGxzZWVrKDB4MywgMCwgMHgyMDAwLCAweGZhZjBh MTQ4LCAwKSAgPSAwCnJlYWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIDY0KSA9IDY0 Cl9sbHNlZWsoMHgzLCAwLCAweDIwMDAsIDB4ZmFmMGExNDgsIDApICA9IDAK cmVhZCgzLCAiXDBcMFwwXDBcMFwwXDBcMCIsIDgpICAgICAgICAgID0gOApf bGxzZWVrKDB4MywgMCwgMHg4MDAwLCAweGZhZjBhMTQ4LCAwKSAgPSAwCnJl YWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMCIuLi4sIDE2OCkgPSAxNjgKX2xsc2VlaygweDMs IDAsIDB4ODAwMCwgMHhmYWYwYTE0OCwgMCkgID0gMApyZWFkKDMsICJcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDAiLi4uLCAyMDQ4KSA9IDIwNDgKX2xsc2VlaygweDMsIDAsIDB4MTAw MDAsIDB4ZmFmMGExNDgsIDApID0gMApyZWFkKDMsICJcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4u LCA2NCkgPSA2NApfbGxzZWVrKDB4MywgMCwgMCwgMHhmYWYwYTE0OCwgMCkg ICAgICAgPSAwCnJlYWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIDgxOTIpID0gODE5 MgpjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAw Cm9wZW4oIi9kZXYvc2RhMTIiLCBPX1JET05MWXxPX0xBUkdFRklMRSkgPSAz CnJlYWQoMywgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIDUxMikgPSA1MTIKY2xvc2UoMykg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMApzdGF0NjQoIi9k ZXYvc2RhMTIiLCB7c3RfbW9kZT0wLCBzdF9zaXplPTYsIC4uLn0pID0gMAph Y2Nlc3MoIi9wcm9jL21vdW50cyIsIFJfT0spICAgICAgICAgICAgPSAwCm9w ZW4oIi9ldGMvbXRhYiIsIE9fUkRPTkxZKSAgICAgICAgICAgICA9IDMKYnJr KDB4NjMwMDApICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHg2MzAw MApmc3RhdDY0KDMsIHtzdF9tb2RlPTAsIHN0X3NpemU9MCwgLi4ufSkgPSAw Cm1tYXAoTlVMTCwgNDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9Q UklWQVRFfE1BUF9BTk9OWU1PVVMsIC0xLCAwKSA9IDB4NDAwMTgwMDAKcmVh ZCgzLCAiL2Rldi9tZDAgLyBleHQzIHJ3LGVycm9ycz1yZW1vdW4iLi4uLCA0 MDk2KSA9IDMzNwpzdGF0NjQoIi9kZXYvbWQwIiwge3N0X21vZGU9MCwgc3Rf c2l6ZT02LCAuLi59KSA9IDAKc3RhdDY0KCJwcm9jIiwgMHhmYWYwMGIwMCkg ICAgICAgICAgICAgID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5KQpzdGF0NjQoImRldnB0cyIsIDB4ZmFmMDBiMDApICAgICAgICAg ICAgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0 YXQ2NCgiL2Rldi9zZGIzIiwge3N0X21vZGU9MCwgc3Rfc2l6ZT02LCAuLi59 KSA9IDAKc3RhdDY0KCIvZGV2L21kMiIsIHtzdF9tb2RlPTAsIHN0X3NpemU9 NiwgLi4ufSkgPSAwCnN0YXQ2NCgiL2Rldi9tZDMiLCB7c3RfbW9kZT0wLCBz dF9zaXplPTYsIC4uLn0pID0gMApzdGF0NjQoIi9kZXYvbWQ0Iiwge3N0X21v ZGU9MCwgc3Rfc2l6ZT02LCAuLi59KSA9IDAKc3RhdDY0KCIvZGV2L21kNSIs IHtzdF9tb2RlPTAsIHN0X3NpemU9NiwgLi4ufSkgPSAwCnN0YXQ2NCgiL2Rl di9tZDYiLCB7c3RfbW9kZT0wLCBzdF9zaXplPTYsIC4uLn0pID0gMApzdGF0 NjQoIi9kZXYvbWQ3Iiwge3N0X21vZGU9MCwgc3Rfc2l6ZT02LCAuLi59KSA9 IDAKc3RhdDY0KCIvZGV2L3NkZDEiLCB7c3RfbW9kZT0wLCBzdF9zaXplPTYs IC4uLn0pID0gMApyZWFkKDMsICIiLCA0MDk2KSAgICAgICAgICAgICAgICAg ICAgICAgPSAwCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA9IDAKbXVubWFwKDB4NDAwMTgwMDAsIDQwOTYpICAgICAgICAgICAg ICAgID0gMApzdGF0NjQoIi9kZXYvc2RhMTIiLCB7c3RfbW9kZT0wLCBzdF9z aXplPTYsIC4uLn0pID0gMApvcGVuKCIvcHJvYy9kZXZpY2VzIiwgT19SRE9O TFl8T19MQVJHRUZJTEUpID0gMwpmc3RhdDY0KDMsIHtzdF9tb2RlPTAsIHN0 X3NpemU9MCwgLi4ufSkgPSAwCm1tYXAoTlVMTCwgNDA5NiwgUFJPVF9SRUFE fFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9BTk9OWU1PVVMsIC0xLCAw KSA9IDB4NDAwMTgwMDAKcmVhZCgzLCAiQ2hhcmFjdGVyIGRldmljZXM6XG4g IDEgbWVtXG4gIDIgcCIuLi4sIDEwMjQpID0gMjI1CmNsb3NlKDMpICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAKbXVubWFwKDB4NDAwMTgw MDAsIDQwOTYpICAgICAgICAgICAgICAgID0gMApvcGVuKCIvcHJvYy9kZXZp Y2VzIiwgT19SRE9OTFl8T19MQVJHRUZJTEUpID0gMwpmc3RhdDY0KDMsIHtz dF9tb2RlPTAsIHN0X3NpemU9MCwgLi4ufSkgPSAwCm1tYXAoTlVMTCwgNDA5 NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9BTk9O WU1PVVMsIC0xLCAwKSA9IDB4NDAwMTgwMDAKcmVhZCgzLCAiQ2hhcmFjdGVy IGRldmljZXM6XG4gIDEgbWVtXG4gIDIgcCIuLi4sIDEwMjQpID0gMjI1CmNs b3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAKbXVu bWFwKDB4NDAwMTgwMDAsIDQwOTYpICAgICAgICAgICAgICAgID0gMApvcGVu KCIvcHJvYy9kZXZpY2VzIiwgT19SRE9OTFl8T19MQVJHRUZJTEUpID0gMwpm c3RhdDY0KDMsIHtzdF9tb2RlPTAsIHN0X3NpemU9MCwgLi4ufSkgPSAwCm1t YXAoTlVMTCwgNDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklW QVRFfE1BUF9BTk9OWU1PVVMsIC0xLCAwKSA9IDB4NDAwMTgwMDAKcmVhZCgz LCAiQ2hhcmFjdGVyIGRldmljZXM6XG4gIDEgbWVtXG4gIDIgcCIuLi4sIDEw MjQpID0gMjI1CnJlYWQoMywgIiIsIDEwMjQpICAgICAgICAgICAgICAgICAg ICAgICA9IDAKY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID0gMAptdW5tYXAoMHg0MDAxODAwMCwgNDA5NikgICAgICAgICAgICAg ICAgPSAwCm9wZW4oIi9wcm9jL2RldmljZXMiLCBPX1JET05MWXxPX0xBUkdF RklMRSkgPSAzCmZzdGF0NjQoMywge3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAu Li59KSA9IDAKbW1hcChOVUxMLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklU RSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHg0MDAx ODAwMApyZWFkKDMsICJDaGFyYWN0ZXIgZGV2aWNlczpcbiAgMSBtZW1cbiAg MiBwIi4uLiwgMTAyNCkgPSAyMjUKcmVhZCgzLCAiIiwgMTAyNCkgICAgICAg ICAgICAgICAgICAgICAgID0gMApjbG9zZSgzKSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPSAwCm11bm1hcCgweDQwMDE4MDAwLCA0MDk2KSAg ICAgICAgICAgICAgICA9IDAKZ2V0dGltZW9mZGF5KHsxMDM1NDgyMjY5LCAx MDMzNjh9LCBOVUxMKSA9IDAKb3BlbigiL2Rldi91cmFuZG9tIiwgT19SRE9O TFkpICAgICAgICAgID0gMwpnZXRwaWQoKSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAzMTIKZ2V0dWlkKCkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgID0gMApnZXR0aW1lb2ZkYXkoezEwMzU0ODIyNjksIDEw OTkxMH0sIE5VTEwpID0gMApnZXR0aW1lb2ZkYXkoezEwMzU0ODIyNjksIDEx MTY2Mn0sIE5VTEwpID0gMApyZWFkKDMsICJcMjA3XDIxMFw0XDM0M1wyMTFc MTBcMzYyXDIwMFwyMFwyMjdRXDM1N1wyNDdcMjE0XDMzN1wyNjYiLi4uLCAx NikgPSAxNgpicmsoMHg3NTAwMCkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPSAweDc1MDAwCnB3cml0ZSg0LCAiXDBcMFwwXDBcMFwwXDBcMFwwXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgNjk2MzIs IDApID0gNjk2MzIKcHdyaXRlKDQsICJYRlNCXDBcMFwyMFwwXDBcMFwwXDAg XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDAiLi4uLCA1MTIsIDAp ID0gNTEyCmZzdGF0NjQoMSwge3N0X21vZGU9MCwgc3Rfc2l6ZT0wLCAuLi59 KSA9IDAKbW1hcChOVUxMLCA0MDk2LCBQUk9UX1JFQUR8UFJPVF9XUklURSwg TUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHg0MDAxODAw MApwd3JpdGUoNCwgIlwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFww XDBcMFwwXDBcMFwwXDBcMFwwXDBcMCIuLi4sIDY1NTM2LCAyMTk5MDIzMTkw MDE2KSA9IC0xIEVOT1NQQyAoTm8gc3BhY2UgbGVmdCBvbiBkZXZpY2UpCndy aXRlKDIsICJta2ZzLnhmczogd3JpdGUgZmFpbGVkOiBObyBzcGFjZSIuLi4s IDQ4bWtmcy54ZnM6IHdyaXRlIGZhaWxlZDogTm8gc3BhY2UgbGVmdCBvbiBk ZXZpY2UKKSA9IDQ4CndyaXRlKDEsICJtZXRhLWRhdGE9L2Rldi9zZGExMiAg ICAgICAgICAgICIuLi4sIDQ1N21ldGEtZGF0YT0vZGV2L3NkYTEyICAgICAg ICAgICAgIGlzaXplPTI1NiAgICBhZ2NvdW50PTUxMiwgYWdzaXplPTEwNDg1 NzYgYmxrcwpkYXRhICAgICA9ICAgICAgICAgICAgICAgICAgICAgICBic2l6 ZT00MDk2ICAgYmxvY2tzPTUzNjg3MDkxMiwgaW1heHBjdD0yNQogICAgICAg ICA9ICAgICAgICAgICAgICAgICAgICAgICBzdW5pdD0wICAgICAgc3dpZHRo PTAgYmxrcywgdW53cml0dGVuPTAKbmFtaW5nICAgPXZlcnNpb24gMiAgICAg ICAgICAgICAgYnNpemU9NDA5NiAgCmxvZyAgICAgID1pbnRlcm5hbCBsb2cg ICAgICAgICAgIGJzaXplPTQwOTYgICBibG9ja3M9MzI3NjgsIHZlcnNpb249 MQogICAgICAgICA9ICAgICAgICAgICAgICAgICAgICAgICBzdW5pdD0wIGJs a3MKcmVhbHRpbWUgPW5vbmUgICAgICAgICAgICAgICAgICAgZXh0c3o9NjU1 MzYgIGJsb2Nrcz0wLCBydGV4dGVudHM9MAopID0gNDU3Cm11bm1hcCgweDQw MDE4MDAwLCA0MDk2KSAgICAgICAgICAgICAgICA9IDAKZXhpdCgxKSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gPwo= --=========3DB03B6D0000037E/mail.tiscali.be-- From owner-linux-xfs@oss.sgi.com Thu Oct 24 10:41:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 10:41:04 -0700 (PDT) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OHf1uR023391 for ; Thu, 24 Oct 2002 10:41:01 -0700 Received: (qmail 11058 invoked from network); 24 Oct 2002 16:52:31 -0000 Received: from laputa.namesys.com.7.16.212.in-addr.arpa (HELO laputa.namesys.com) (212.16.7.124) by thebsh.namesys.com with SMTP; 24 Oct 2002 16:52:31 -0000 Received: by laputa.namesys.com (Postfix on SuSE Linux 8.0 (i386), from userid 511) id 235DD24B7A; Thu, 24 Oct 2002 20:52:30 +0400 (MSD) From: Nikita Danilov MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-ID: <15800.9549.974775.3912@laputa.namesys.com> Date: Thu, 24 Oct 2002 20:52:29 +0400 X-PGP-Fingerprint: 43CE 9384 5A1D CD75 5087 A876 A1AA 84D0 CCAA AC92 X-PGP-Key-ID: CCAAAC92 X-PGP-Key-At: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xCCAAAC92 To: Fabien Combernous Cc: ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com Subject: Re: [reiserfs-list] To compare Linux journalised filesystem, part II. In-Reply-To: <3DB823AA.6010405@eprocess.fr> References: <3DB823AA.6010405@eprocess.fr> X-Mailer: VM 7.07 under 21.5 (beta6) "bok choi" XEmacs Lucid X-Emacs-Acronym: Emetic Macros Assault Core and Segmentation X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nikita@Namesys.COM Precedence: bulk X-list: linux-xfs Fabien Combernous writes: > Back, > > After to get all informations i received, i put them in table as follow: > > see attachment file. > > Specialists can they tell me if they agree with my conclusions ? > > Thank's for your good job. > > Fabien. > > -- > > Fabien COMBERNOUS - IT Engineer > eProcess - Parc Club du Mill閚aire Batiment n 6 > 1025 rue Henri Becquerel - 34000 Montpellier FRANCE > http://www.eprocess.fr - +33 (0)4 67 13 84 50 > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | Features \ fs | xfs | ext3 | jfs | reiserfs | Comments | > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | mmutable | N | Y | Y | Y | "Y" is not with same sens. Implementation is not same. Each one permit | > | append-only | | | | | some elements that other don't permit and reverse. xfs will have | > | | | | | | implementation in futur. | > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | quotas | Y | Y | Y | Y | Again "Y" is not aqual. ext3 accept quota only on data-journaled | > | | | | | | filesystems, but all other journaled filesystem don't have data journal| > | | | | | | About reiserfs you need Chris patches. > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | NFS | Y | Y | Y | Y | nfs works on all of them. You need at least reiserfs v3.6. > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | samba | Y | Y | Y | Y | Since Samba is userspace, the fs shouldn't matter (2.2.4 or 2.2.5) | > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | coda | coda is a file sys him self | / / / / | > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > |data journal | N | Y | N | N | Only ext3 can take care of data by a data journal. All other journaled | > | | | | | | file systems have "only" a metadata journal. | > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ Reiserfs supports data journalling with yet another set of Chris patches: ftp://ftp.suse.com/pub/people/mason/patches/data-logging/ Nikita. From owner-linux-xfs@oss.sgi.com Thu Oct 24 13:01:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 13:01:37 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OK1UuR025262 for ; Thu, 24 Oct 2002 13:01:31 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9OK1C3c001559 for ; Thu, 24 Oct 2002 15:01:12 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9OK0CV9001540; Thu, 24 Oct 2002 15:00:12 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Curious about mount options and Direct IO. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 14:59:12 -0500 Message-Id: <1035489552.1472.7.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1247 X-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 What benefits, if any, would we see by using direct IO with XFS on very large FS?(like 300 and 500GB FS) TIA Austin From owner-linux-xfs@oss.sgi.com Thu Oct 24 13:05:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 13:05:11 -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 g9OK58uR026524 for ; Thu, 24 Oct 2002 13:05:09 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id EE3251EDCEB; Thu, 24 Oct 2002 13:05:21 -0700 (PDT) Date: Thu, 24 Oct 2002 13:05:21 -0700 From: Chris Wedgwood To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Curious about mount options and Direct IO. Message-ID: <20021024200521.GA17994@tapu.f00f.org> References: <1035489552.1472.7.camel@ubergeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1035489552.1472.7.camel@ubergeek> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1248 X-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 24, 2002 at 02:59:12PM -0500, Austin Gonyou wrote: > What benefits, if any, would we see by using direct IO with XFS on > very large FS?(like 300 and 500GB FS) It depends what you are doing... --cw From owner-linux-xfs@oss.sgi.com Thu Oct 24 13:12:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 13:12:48 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OKChuR027162 for ; Thu, 24 Oct 2002 13:12:44 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9OKCK3c001585; Thu, 24 Oct 2002 15:12:20 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9OKBIER001577; Thu, 24 Oct 2002 15:11:18 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Re: Curious about mount options and Direct IO. From: Austin Gonyou To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021024200521.GA17994@tapu.f00f.org> References: <20021024200521.GA17994@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 15:10:18 -0500 Message-Id: <1035490218.1472.11.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1249 X-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-24 at 15:05, Chris Wedgwood wrote: > On Thu, Oct 24, 2002 at 02:59:12PM -0500, Austin Gonyou wrote: > > > What benefits, if any, would we see by using direct IO with XFS on > > very large FS?(like 300 and 500GB FS) > > It depends what you are doing... I agree, but I guess my question was a general question about XFS's capabilities to actually do anything in a DIO mode.I didn't see any mount options for DirectIO, just osyncisdsync. Our app is Oracle, but I can't see that anything will really benefit beyond relieving the logging(logbufs=8). > > --cw From owner-linux-xfs@oss.sgi.com Thu Oct 24 13:23:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 13:23:10 -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 g9OKN8uR027738 for ; Thu, 24 Oct 2002 13:23:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA72188 for ; Thu, 24 Oct 2002 15:23:15 -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 PAA14492 for ; Thu, 24 Oct 2002 15:23:15 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9OKIYO23490; Thu, 24 Oct 2002 15:18:34 -0500 Message-Id: <200210242018.g9OKIYO23490@stout.americas.sgi.com> Date: Thu, 24 Oct 2002 15:18:34 -0500 Subject: TAKE - Implement xfs_panic_mask X-archive-position: 1250 X-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 might help diagnose some force shutdown scenarios... There is now a /proc/sys/fs/xfs/panic_mask sysctl which can be set with this bitmask: #define XFS_NO_PTAG 0LL #define XFS_PTAG_IFLUSH 0x0000000000000001LL #define XFS_PTAG_LOGRES 0x0000000000000002LL #define XFS_PTAG_AILDELETE 0x0000000000000004LL #define XFS_PTAG_AVAILABLE 0x0000000000000008LL #define XFS_PTAG_SHUTDOWN_CORRUPT 0x0000000000000010LL #define XFS_PTAG_SHUTDOWN_IOERROR 0x0000000000000020LL #define XFS_PTAG_SHUTDOWN_LOGERROR 0x0000000000000040LL this will cause various things that would normally just be errors to BUG(), from which we can get a backtrace. Implement xfs_panic_mask Date: Thu Oct 24 13:18:15 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:131027a linux/fs/xfs/xfs_rw.c - 1.368 - hook forced shutdown into panic_mask handling linux/fs/xfs/xfs_error.c - 1.36 linux/fs/xfs/xfs_error.h - 1.28 - define more panic tags for force shutdown linux/fs/xfs/linux/xfs_globals.c - 1.39 linux/fs/xfs/linux/xfs_linux.h - 1.91 - #define xfs_panic_mask as a sysctl parameter linux/fs/xfs/linux/xfs_sysctl.c - 1.12 - set up xfs_panic_mask sysctl From owner-linux-xfs@oss.sgi.com Thu Oct 24 13:37:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 13:37: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 g9OKbBuR028284 for ; Thu, 24 Oct 2002 13:37:11 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 38F191EDD05; Thu, 24 Oct 2002 13:37:24 -0700 (PDT) Date: Thu, 24 Oct 2002 13:37:24 -0700 From: Chris Wedgwood To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Curious about mount options and Direct IO. Message-ID: <20021024203724.GA18238@tapu.f00f.org> References: <20021024200521.GA17994@tapu.f00f.org> <1035490218.1472.11.camel@ubergeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1035490218.1472.11.camel@ubergeek> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1251 X-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 24, 2002 at 03:10:18PM -0500, Austin Gonyou wrote: > I agree, but I guess my question was a general question about XFS's > capabilities to actually do anything in a DIO mode.I didn't see any > mount options for DirectIO, just osyncisdsync. XFS under Linux supports O_DIRECT. For some applications, it's a bug win, for others, it's not. > Our app is Oracle, but I can't see that anything will really benefit > beyond relieving the logging(logbufs=8). O_DIRECT means reduced memcpy when doing a read reduced memcpy when doing a write *much* lower vm pressure when doing lots of IO (eg. a table-scan of 2GB of data won't evict all your cached pages on 1GB box) I use O_DIRECT mostly because of the last issue... when writing multi-GB files, I don't want my desktop to start swapping or evicting useful data from cache. All there help with performance, but to what degress depends on what you are doing and how well implemented it is. I would think Oracle already uses O_DIRECT and is pretty well tuned for it, but I don't know for sure, you'll have to ask. --cw From owner-linux-xfs@oss.sgi.com Thu Oct 24 14:14:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 14:14:16 -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 g9OLEDuR029811 for ; Thu, 24 Oct 2002 14:14:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA63094; Thu, 24 Oct 2002 12:37:11 -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 MAA98906; Thu, 24 Oct 2002 12:37:11 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9OHXBm30730; Thu, 24 Oct 2002 12:33:11 -0500 Subject: Re: [reiserfs-list] Re: [ext3-users] To compare Linux journalised filesystem, part II. From: Steve Lord To: Fabien Combernous Cc: Chris Mason , Andreas Dilger , Fabien Combernous , ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com In-Reply-To: <1035480451.30133.192.camel@tiny> References: <3DB823AA.6010405@eprocess.fr> <20021024170826.GI28822@clusterfs.com> <1035480451.30133.192.camel@tiny> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Oct 2002 12:33:11 -0500 Message-Id: <1035480791.30513.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1252 X-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-24 at 12:27, Chris Mason wrote: > On Thu, 2002-10-24 at 13:08, Andreas Dilger wrote: > > On Oct 24, 2002 18:45 +0200, Fabien Combernous wrote: > > > +--------+------------------------------------------------------------------+ > > > | quotas | Again "Y" is not aqual. ext3 accept quota only on data-journaled | > > > | | filesystems, but all other journaled filesystem don't have data | > > > +--------+------------------------------------------------------------------+ > > > > Granted that I have never used quotas, so it is possible that I > > am incorrect. However, my understanding is that yes, you do need > > data-journaled quota files to ensure that your quota tables don't miss > > some operations after a crash. However, you can separately select > > data journaling for files in ext3 (via chattr), even if the rest of > > the filesystem is using data=ordered (the default). > > data journaling on the quota files is better. Some quota updates (dqput > calling commit_dquot) are done only by clear_inode(), which should > happen outside the transaction and won't be grouped with the actual > metadata change. > XFS quota file updates are transactional with the original metadata change which allocated or freed space. So while we do not have data journalling, quota updates are journalled. 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 24 14:44:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 14:44:59 -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 g9OLivuR030430 for ; Thu, 24 Oct 2002 14:44:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA26303 for ; Thu, 24 Oct 2002 16:45:05 -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 QAA87601 for ; Thu, 24 Oct 2002 16:45:04 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9OLeNS23675; Thu, 24 Oct 2002 16:40:23 -0500 Message-Id: <200210242140.g9OLeNS23675@stout.americas.sgi.com> Date: Thu, 24 Oct 2002 16:40:23 -0500 Subject: TAKE - Missing bit of xfs_panic_mask X-archive-position: 1253 X-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 Whoops, missed one file, tree should build again now, sorry! That's what I get for having too many changes in one workarea.... Missing bit of xfs_panic_mask Date: Thu Oct 24 14:44:30 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:131040a linux/fs/xfs/linux/xfs_sysctl.h - 1.7 From owner-linux-xfs@oss.sgi.com Thu Oct 24 14:48:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 14:48:41 -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 g9OLmcuR030873 for ; Thu, 24 Oct 2002 14:48:38 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA33961; Thu, 24 Oct 2002 16:48: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 QAA75577; Thu, 24 Oct 2002 16:48:45 -0500 (CDT) Subject: Re: Curious about mount options and Direct IO. From: Eric Sandeen To: Austin Gonyou Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <1035490218.1472.11.camel@ubergeek> References: <20021024200521.GA17994@tapu.f00f.org> <1035490218.1472.11.camel@ubergeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 24 Oct 2002 16:44:03 -0500 Message-Id: <1035495844.9368.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1254 X-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 O_DIRECT is not a mount option, you open a file with that flag, and do I/O in a prescribed fashion. You can't "magically" get O_DIRECT behavior across a filesystem with just a mount option. An old paper on what O_DIRECT is, is at http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html -Eric On Thu, 2002-10-24 at 15:10, Austin Gonyou wrote: > > I agree, but I guess my question was a general question about XFS's > capabilities to actually do anything in a DIO mode.I didn't see any > mount options for DirectIO, just osyncisdsync. -- 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 Thu Oct 24 15:05:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:05:33 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-160.uc.nombres.ttd.es [213.99.177.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OM5MuR031587 for ; Thu, 24 Oct 2002 15:05:25 -0700 Received: (qmail 20300 invoked by uid 1000); 24 Oct 2002 22:06:39 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 00:06:39 +0200 To: linux-xfs Subject: About removing files Message-ID: <20021024220639.GA20279@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have experienced large times when deleting a few big files (they were ISO images). Why do XFS waste such time for deleting that files? Note: It happends to me a lot of times... Process: I make, record and finally delete the ISO image. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uG7vWIvihXTx06wRArJtAKCbw8BAOW1s/RDrgBbRF7vCZj/m9gCbB6t0 IhSIfSfGviiwc4DoENeSJoA= =vF3v -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-linux-xfs@oss.sgi.com Thu Oct 24 15:14:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:14:15 -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 g9OMECuR032064 for ; Thu, 24 Oct 2002 15:14:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA40943; Thu, 24 Oct 2002 17:14: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 RAA10281; Thu, 24 Oct 2002 17:14:19 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9OMAIv03396; Thu, 24 Oct 2002 17:10:18 -0500 Subject: Re: About removing files From: Steve Lord To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021024220639.GA20279@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Oct 2002 17:10:18 -0500 Message-Id: <1035497418.31455.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1256 X-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-24 at 17:06, yoros@wanadoo.es wrote: > > Hi, > > I have experienced large times when deleting a few big files (they were > ISO images). Why do XFS waste such time for deleting that files? > > Note: It happends to me a lot of times... Process: I make, record and > finally delete the ISO image. > > Pedro Depends which version of the code you are running, and how you create the iso. If your file is really fragmented then it might well take a while. If you are running the 1.1 release or earlier then you are probably running code which has some synchronous disk writes in the delete path. This is no longer the case in the latest code. Try running xfs_bmap on your iso file, this outputs how the file is layed out on disk. If it is in lots of small chunks then that is part of the problem and you might want to look at how you create the iso images (and tell us how you do it too). 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 24 15:37:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:37:53 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OMbouR000346 for ; Thu, 24 Oct 2002 15:37:51 -0700 Received: from UberGeek (localhost.localdomain [127.0.0.1]) by UberGeek (8.12.5/8.12.5) with ESMTP id g9OMbV3c001925; Thu, 24 Oct 2002 17:37:31 -0500 Received: (from agonyou@localhost) by UberGeek (8.12.5/8.12.5/Submit) id g9OMaVN5001919; Thu, 24 Oct 2002 17:36:31 -0500 X-Authentication-Warning: UberGeek: agonyou set sender to austin@coremetrics.com using -f Subject: Re: Curious about mount options and Direct IO. From: Austin Gonyou To: Eric Sandeen Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <1035495844.9368.12.camel@stout.americas.sgi.com> References: <1035495844.9368.12.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 17:35:30 -0500 Message-Id: <1035498930.1472.18.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1257 X-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 Kewl Thanks Much! :) On Thu, 2002-10-24 at 16:44, Eric Sandeen wrote: > O_DIRECT is not a mount option, you open a file with that flag, and do > I/O in a prescribed fashion. You can't "magically" get O_DIRECT > behavior across a filesystem with just a mount option. > > An old paper on what O_DIRECT is, is at > http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.ht > ml > > -Eric > > On Thu, 2002-10-24 at 15:10, Austin Gonyou wrote: > > > > I agree, but I guess my question was a general question about XFS's > > capabilities to actually do anything in a DIO mode.I didn't see any > > mount options for DirectIO, just osyncisdsync. > > > -- > 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 Thu Oct 24 15:46:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:46:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OMkeuR000867 for ; Thu, 24 Oct 2002 15:46:40 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9OMkruI100262 for ; Thu, 24 Oct 2002 18:46:53 -0400 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OMkpqq224612 for ; Thu, 24 Oct 2002 16:46:52 -0600 Subject: XFS file locking questions To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Thu, 24 Oct 2002 17:46:28 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/24/2002 04:46:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs What types of file locking are supported by XFS (if any)? In particular, does it support range locking? Regards, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Thu Oct 24 15:52:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:52: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 g9OMqsuR001313 for ; Thu, 24 Oct 2002 15:52:54 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA27987; Thu, 24 Oct 2002 17:53:02 -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 RAA57203; Thu, 24 Oct 2002 17:53:01 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9OMn0W03452; Thu, 24 Oct 2002 17:49:00 -0500 Subject: Re: XFS file locking questions From: Steve Lord To: James A Goodwin Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Oct 2002 17:49:00 -0500 Message-Id: <1035499740.31455.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1259 X-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-24 at 17:46, James A Goodwin wrote: > What types of file locking are supported by XFS (if any)? > > In particular, does it support range locking? > > Regards, > File locking should all work, in linux 99% of it is in the vfs code, all the filesystem gets to be involved in is maintaining the fact that mandatory locks are present on the inode. I think. Now you might discover some scaling issues in the linux file locking implementation, but that is a generic linux issue, not an xfs one. Some attempts have been made at making it scale better. 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 24 15:55:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 15:55:07 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-160.uc.nombres.ttd.es [213.99.177.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OMsuuR001752 for ; Thu, 24 Oct 2002 15:54:58 -0700 Received: (qmail 20876 invoked by uid 1000); 24 Oct 2002 22:56:14 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 00:56:14 +0200 To: linux-xfs Subject: Re: About removing files Message-ID: <20021024225614.GA20660@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <1035497418.31455.13.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 24, 2002 at 05:10:18PM -0500, Steve Lord wrote: > Depends which version of the code you are running, and how you > create the iso. If your file is really fragmented then it might > well take a while. If you are running the 1.1 release or earlier > then you are probably running code which has some synchronous > disk writes in the delete path. This is no longer the case in > the latest code. >=20 > Try running xfs_bmap on your iso file, this outputs how the > file is layed out on disk. If it is in lots of small chunks > then that is part of the problem and you might want to look > at how you create the iso images (and tell us how you do it too). Good, I have applied xfs_bmap to a few files... I get a lot of extents in some files and only a few of that in others. xfs_bmap -l xxxx.avi | wc -l ----> 48800 xfs_bmap -l xxxx.iso | wc -l ----> 115 Now I don't have a most-fragmented ISO, but I found a most-fragmented file. That file has about 20-40-50 blocks for each extent. Here is my questions: =BFHow can I obtain better performance? =BFDoes the number of blocks for extent related to creating/writting method? Thank you for all this information, I am learning... Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uHqNWIvihXTx06wRAv+9AJ9WJdZQXGUzebz832IB11hwy5FuzgCfYpE8 K7ySxVYNQ/CUgDZdQFD0bWQ= =mQSD -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-linux-xfs@oss.sgi.com Thu Oct 24 16:17:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 16:17:40 -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 g9ONHcuR002558 for ; Thu, 24 Oct 2002 16:17:38 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 094A61EDD70; Thu, 24 Oct 2002 16:17:51 -0700 (PDT) Date: Thu, 24 Oct 2002 16:17:51 -0700 From: Chris Wedgwood To: James A Goodwin Cc: linux-xfs@oss.sgi.com Subject: Re: XFS file locking questions Message-ID: <20021024231751.GB19254@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: 1262 X-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 24, 2002 at 05:46:28PM -0500, James A Goodwin wrote: > What types of file locking are supported by XFS (if any)? Pretty much all locking is done on the VFS above the filesystem. Locking methods should therefore work with all filesystems in pretty much the same way. --cw From owner-linux-xfs@oss.sgi.com Thu Oct 24 16:16:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 16:16:48 -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 g9ONGguR002363 for ; Thu, 24 Oct 2002 16:16:42 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 6F39A1EDD50; Thu, 24 Oct 2002 16:16:56 -0700 (PDT) Date: Thu, 24 Oct 2002 16:16:56 -0700 From: Chris Wedgwood To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: About removing files Message-ID: <20021024231656.GA19254@tapu.f00f.org> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20021024225614.GA20660@morpheus.matrix.com> User-Agent: Mutt/1.4i X-No-Archive: Yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9ONGhuR002364 X-archive-position: 1261 X-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 25, 2002 at 12:56:14AM +0200, yoros@wanadoo.es wrote: > xfs_bmap -l xxxx.avi | wc -l ----> 48800 Wow... that's terrible. How full is this filesystem? For reference, looking at a backup drive: # ls -lh homefs -rw-r--r-- 1 root root 11G Oct 22 00:15 homefs # xfs_bmap homefs|wc -l 5 > xfs_bmap -l xxxx.iso | wc -l ----> 115 How large are these files? > Here is my questions: 縃ow can I obtain better performance? 緿oes > the number of blocks for extent related to creating/writting method? XFS will try to minimize fragmention, however, the ability for it to do this is thwarted if the filesystem gets very full. Might this be the case for you? If the filesystem was previously very full, but not has a fair amount of space available, you could try "xfs_fsr -v -d xxxx.avi" or similar. --cw From owner-linux-xfs@oss.sgi.com Thu Oct 24 18:57:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 18:57:14 -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 g9P1vAuR004713 for ; Thu, 24 Oct 2002 18:57:10 -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 SAA01288 for ; Thu, 24 Oct 2002 18:57:23 -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 LAA20015; Fri, 25 Oct 2002 11:55:48 +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 g9P1t0Vg001091; Fri, 25 Oct 2002 11:55:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g9P1sxIu001089; Fri, 25 Oct 2002 11:54:59 +1000 Date: Fri, 25 Oct 2002 11:54:59 +1000 From: Nathan Scott To: jsoe0708@tiscali.be Cc: linux-xfs@oss.sgi.com Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa Message-ID: <20021025015459.GD687@frodo> References: <20021024120735.B11816@infradead.org> <3DB03B6D0000037E@ocpmta6.be.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB03B6D0000037E@ocpmta6.be.tiscali.com> User-Agent: Mutt/1.4i X-archive-position: 1263 X-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 Thu, Oct 24, 2002 at 07:37:33PM +0200, jsoe0708@tiscali.be wrote: > Hi Christoph, > > > >Can you send me the strace output for strace mkfs.xfs /dev/sda12? > > > Here you are: > > execve("/sbin/mkfs.xfs", ["mkfs.xfs", "/dev/sda12"], [/* 15 vars */]) = 0 > ... > pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 69632, > 0) = 69632 > pwrite(4, "XFSB\0\0\20\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512, > 0) = 512 > fstat64(1, {st_mode=0, st_size=0, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x40018000 > pwrite(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536, > 2199023190016) = -1 ENOSPC (No space left on device) > write(2, "mkfs.xfs: write failed: No space"..., 48mkfs.xfs: write failed: > No space left on device Looks like mkfs.xfs is trying to write past the end of the device. Possibly the BLKGETSIZE64 ioctl has been mishandled by the device driver? 2199023190016 is a fairly large byte offset. This ioctl is called from in cmd/xfsprogs/libxfs/init.c::findsize so that's probably a good place to start debugging. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 24 19:24:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 19:24:12 -0700 (PDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P2O5uR005356 for ; Thu, 24 Oct 2002 19:24:06 -0700 Received: from user-1120033.dsl.mindspring.com ([66.32.0.99] helo=[172.16.0.25]) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 184u95-0006Uy-00 for linux-xfs@oss.sgi.com; Thu, 24 Oct 2002 22:24:19 -0400 Subject: 1.2-pre2 athalon kernel rpm? From: Chris Weyl To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 22:38:28 -0400 Message-Id: <1035513511.21354.51.camel@remus> Mime-Version: 1.0 X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cweyl@alumni.drew.edu Precedence: bulk X-list: linux-xfs Hi all, Quick question. Does there happen to be an athalon version of the -pre2 kernel kicking around somewhere? I'd like to upgrade from the i686 (sigh) kernel that the installer decided to give me, and figured I may as well use the -pre2:-) Thanks- -Chris From owner-linux-xfs@oss.sgi.com Thu Oct 24 19:36:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 19:36:33 -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 g9P2aUuR005896 for ; Thu, 24 Oct 2002 19:36:31 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA53368; Thu, 24 Oct 2002 21:36: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 VAA07955; Thu, 24 Oct 2002 21:36:39 -0500 (CDT) Date: Thu, 24 Oct 2002 21:31:55 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Chris Weyl cc: linux-xfs@oss.sgi.com Subject: Re: 1.2-pre2 athalon kernel rpm? In-Reply-To: <1035513511.21354.51.camel@remus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1265 X-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 Guess it didn't get built... I'll whip one up, shouldn't take too long. -Eric On 24 Oct 2002, Chris Weyl wrote: > Hi all, > > Quick question. Does there happen to be an athalon version of the -pre2 > kernel kicking around somewhere? I'd like to upgrade from the i686 > (sigh) kernel that the installer decided to give me, and figured I may > as well use the -pre2:-) > > Thanks- > -Chris > > > > > From owner-linux-xfs@oss.sgi.com Thu Oct 24 22:17:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Oct 2002 22:17:13 -0700 (PDT) Received: from morpheus.matrix.com (213-99-177-160.uc.nombres.ttd.es [213.99.177.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P5H5uR009035 for ; Thu, 24 Oct 2002 22:17:06 -0700 Received: (qmail 22435 invoked by uid 1000); 25 Oct 2002 05:18:20 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 07:18:20 +0200 To: linux-xfs Subject: Re: About removing files Message-ID: <20021025051820.GA22414@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20021024231656.GA19254@tapu.f00f.org> User-Agent: Mutt/1.4i X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have executed xfs_fsr and with a very good results (thank you). My intention is to know why this situations may happend and why XFS is slow deleting files and directories. Well, if anybody has time to explain me this methods... Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uNQcWIvihXTx06wRAsFHAJ4trAgCRDQlUNpkbO5QH+55lvW6zgCfe7iM qQuN4BKS6duB1rgFn27zV30= =aAL5 -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-linux-xfs@oss.sgi.com Fri Oct 25 01:36:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 01:36:22 -0700 (PDT) Received: from neutron.toe.cssgroup.net (adsl-208-188-150-2.lefthemisphere.com [208.188.150.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P8aHuR020915 for ; Fri, 25 Oct 2002 01:36:17 -0700 Received: from [192.168.196.27] ([192.168.196.27]) by neutron.toe.cssgroup.net (Build 101 8.9.3/NT-8.9.3) with SMTP id DAA31388 for ; Fri, 25 Oct 2002 03:36:27 -0500 Message-Id: <200210250836.DAA31388@neutron.toe.cssgroup.net> Mime-Version: 1.0 Content-type: text/html; charset="US-Ascii" Content-Transfer-Encoding: 7bit Date: Fri, 25 Oct 2002 03:32:41 -0500 To: linux-xfs@oss.sgi.com From: Info Subject: Digitally Connect to Your Customers X-archive-position: 1267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Info@cssgroup.net Precedence: bulk X-list: linux-xfs
CSS is looking for companies that are interested
in working with
DataManager's Asset Management version 3.1.




We are looking for a few aggressive qualified companies that
want to improve their bottom line, while providing their Customers
online integration of their jobs, and job files.




Contact us at CSS Group 1-800-448-8432, or visit our web page at http://www.cssgroup.net



Click the following link to send a removal request to CSS Group. Remove Requests
If you wish to remove an e-mail address other than your own please indicate this in the e-mail. From owner-linux-xfs@oss.sgi.com Fri Oct 25 02:00:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 02:00:32 -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 g9P90KuR021544 for ; Fri, 25 Oct 2002 02:00:20 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 5FF6C1EDDEC; Fri, 25 Oct 2002 01:33:09 -0700 (PDT) Date: Fri, 25 Oct 2002 01:33:09 -0700 From: Chris Wedgwood To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: About removing files Message-ID: <20021025083309.GA22766@tapu.f00f.org> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025051820.GA22414@morpheus.matrix.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1268 X-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 25, 2002 at 07:18:20AM +0200, yoros@wanadoo.es wrote: > My intention is to know why this situations may happend and why XFS > is slow deleting files and directories. *If* the filesystem gets very full, files will tend to become fragmented. This is not unique to XFS. > Well, if anybody has time to explain me this methods... How full was your filesystem? Has it every been completely full? I ask this because many people I've dealt with with badly fragmented filesystems have had completely full filesystems... in such cases, things are going to fragment or fail. --cw From owner-linux-xfs@oss.sgi.com Fri Oct 25 03:55:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 03:55:35 -0700 (PDT) Received: from e4.eyal.emu.id.au (CPE-203-51-26-24.nsw.bigpond.net.au [203.51.26.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PAtUuR026501 for ; Fri, 25 Oct 2002 03:55:31 -0700 Received: from eyal.emu.id.au (e7.eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id g9PAtk029013 for ; Fri, 25 Oct 2002 20:55:46 +1000 Received: from eyal.emu.id.au (really [192.168.2.7]) by eyal.emu.id.au via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 25 Oct 2002 20:55:40 +1000 (EST) Message-ID: <3DB9232C.9C6099EB@eyal.emu.id.au> Date: Fri, 25 Oct 2002 20:55:40 +1000 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20-pre9 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs list Subject: "Corruption of in-memory data detected" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eyal@eyal.emu.id.au Precedence: bulk X-list: linux-xfs This is at the office. An SMP (2xAthlon MP 2000) machine with 1GB memory. The fs is exported via NFA and it was forced down when a user (on another machine) was deleting files off NFS. The kernel was build from CVS (linux-2.4-xfs) as of last weekend (19/20 Oct). We dropped back to a version a few months old which was used well on another, similar machine. =========================== xfs_force_shutdown(sd(8,0),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xf88ddfb7 Corruption of in-memory data detected. Shutting down filesystem: sd(8,0) Please umount the filesystem, and rectify the problem(s) =========================== The system mounted OK after a reboot. Should I check or fix the fs now? -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Fri Oct 25 04:05:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 04:05:42 -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 g9PB5ZuR027406 for ; Fri, 25 Oct 2002 04:05:36 -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 g9PB5VJU084421; Fri, 25 Oct 2002 13:05:33 +0200 (CEST) Message-Id: <4.3.2.7.2.20021025130315.03ef4b78@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Oct 2002 13:04:19 +0200 To: Eyal Lebedinsky , linux-xfs list From: Seth Mos Subject: Re: "Corruption of in-memory data detected" In-Reply-To: <3DB9232C.9C6099EB@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1270 X-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 20:55 25-10-2002 +1000, Eyal Lebedinsky wrote: >This is at the office. An SMP (2xAthlon MP 2000) machine with >1GB memory. > >The fs is exported via NFA and it was forced down when a user >(on another machine) was deleting files off NFS. > >The kernel was build from CVS (linux-2.4-xfs) as of last >weekend (19/20 Oct). We dropped back to a version a few >months old which was used well on another, similar machine. > > >=========================== >xfs_force_shutdown(sd(8,0),0x8) called from line 1042 of file >xfs_trans.c. Return address = 0xf88ddfb7 >Corruption of in-memory data detected. Shutting down filesystem: >sd(8,0) >Please umount the filesystem, and rectify the problem(s) >=========================== > > >The system mounted OK after a reboot. Should I check or >fix the fs now? That might be a very wise thing to do. Check first, then fix. Sometimes this sort of failure could have generated a problem which would only show later and probably produce a oops. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Oct 25 04:29:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 04:29:23 -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 g9PBTJuR028403 for ; Fri, 25 Oct 2002 04:29:20 -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 41A6J92K; Fri, 25 Oct 2002 07:29:41 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g9PBTYM31104; Fri, 25 Oct 2002 07:29:34 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3DB92B1E.2010807@wgate.com> Date: Fri, 25 Oct 2002 07:29:34 -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: yoros@wanadoo.es CC: linux-xfs Subject: Re: About removing files References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1271 X-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 yoros@wanadoo.es wrote: > Hi, > > I have executed xfs_fsr and with a very good results (thank you). > > My intention is to know why this situations may happend and why XFS is > slow deleting files and directories. First, I must say that I have not found XFS (the current versions) to be slow in delete at all. Try running FreeBSD once :-) However, it is fundamentally true that a journalled file system (such as XFS, EXT3, JFS, etc) will be slower in operations that have large metadata impacts. That is, anything that affects the structure on disk (where files are, where empty space is, etc) will be written to the journal in case of a crash/failure before all of the disk structures could be updated. This is how such filesystems can be remounted in moments after a crash without an extensive fsck pass to revalidate the file system structure. EXT2 is *very* fast at deleting whole directory trees since it does so all in its cache and then writes things out to disk as it gets time. XFS is not that fast. But it is rather fast. BTW - I have had slow open(O_CREAT|O_TRUNC) on EXT2 when the file already existed and was large... XFS is very much faster at that on my systems. (This was overwriting files in the 500+MB range) -- 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 Fri Oct 25 04:36:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 04:36:07 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PBa4uR028874 for ; Fri, 25 Oct 2002 04:36:05 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9PBaEf24684 for ; Fri, 25 Oct 2002 07:36:14 -0400 Message-ID: <3DB92CAF.775874FA@splentec.com> Date: Fri, 25 Oct 2002 07:36:15 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: xfs locking -- stack dump Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs This is a dump of the stack for mount after it goes in D state. This happens on the 2nd time of mount, strangely the 1st time it succeeds. Trace; c0107e52 <__down+82/d0> Trace; c0107fec <__down_failed+8/c> Trace; c02b83bc <.text.lock.page_buf+ce/172> Trace; c02c0bbe Trace; c02b4c98 Trace; c029c034 Trace; c029d45c Trace; c029d563 Trace; c029ce65 Trace; c02a0a07 Trace; c02984c4 Trace; c02a1fb3 Trace; c02b83bc <.text.lock.page_buf+ce/172> Trace; c02a16c9 Trace; c02aaf4e Trace; c02c1d92 Trace; c014cf6a Trace; c014d942 Trace; c014cebb Trace; c014dce4 Trace; c0162b63 Trace; c0162ea0 Trace; c0162ce9 Trace; c01633af Trace; c01094ab The setup is as per BUG 182, except that the array is 3 disks and 1 spare, chunk-size 4 and has finished syncing. lvm 1.1-rc2 on top. My question is why is the lock called twice...? As I said, this happens only the second time mount is attempted. < clue) Second: has anyone looked at _pagebuf_page_io()? Is this fn expected to always unlock the page? Maybe this is why we are getting bug 182 when using chunk-size > page_size? That is, shouldn't this locking be like (not real C code): do_io_page(pg) { if (locking) lock_page(pg); do_io(pg); if (locking) unlock_page(pg); } And in this way this locking will be out of the low-level io fn. Also, what is the purpose of pb_locked? If this is _any_ kind of lock, should it be atomic, bitops, or at least volatile? I'm seeing this locking scattered all over pagebuf/ and have been wondering if it should be pulled out like the example above? Sorry for the dumb questions, but I have only been looking at the code for a couple of days and am trying to get this working... -- Luben From owner-linux-xfs@oss.sgi.com Fri Oct 25 05:11:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 05:11:11 -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 g9PCB6uR030918 for ; Fri, 25 Oct 2002 05:11:06 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA68057; Fri, 25 Oct 2002 07:11:16 -0500 (CDT) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-20.corp.sgi.com [134.15.64.20]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA78998; Fri, 25 Oct 2002 07:11:13 -0500 (CDT) Subject: Re: xfs locking -- stack dump From: Stephen Lord To: Luben Tuikov Cc: linux-xfs In-Reply-To: <3DB92CAF.775874FA@splentec.com> References: <3DB92CAF.775874FA@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Oct 2002 07:07:01 -0500 Message-Id: <1035547623.1437.28.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1273 X-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-25 at 06:36, Luben Tuikov wrote: > This is a dump of the stack for mount after it > goes in D state. This happens on the 2nd time > of mount, strangely the 1st time it succeeds. > > Trace; c0107e52 <__down+82/d0> > Trace; c0107fec <__down_failed+8/c> > Trace; c02b83bc <.text.lock.page_buf+ce/172> > Trace; c02c0bbe > Trace; c02b4c98 > Trace; c029c034 > Trace; c029d45c > Trace; c029d563 > Trace; c029ce65 > Trace; c02a0a07 > Trace; c02984c4 > Trace; c02a1fb3 > Trace; c02b83bc <.text.lock.page_buf+ce/172> > Trace; c02a16c9 > Trace; c02aaf4e > Trace; c02c1d92 > Trace; c014cf6a > Trace; c014d942 > Trace; c014cebb > Trace; c014dce4 > Trace; c0162b63 > Trace; c0162ea0 > Trace; c0162ce9 > Trace; c01633af > Trace; c01094ab > > The setup is as per BUG 182, except that the > array is 3 disks and 1 spare, chunk-size 4 and > has finished syncing. lvm 1.1-rc2 on top. > > My question is why is the lock called twice...? > As I said, this happens only the second time > mount is attempted. < clue) These stack dumps are confusing, all the output is doing is reporting where it found a code address on the stack, it does not mean it is a currently active stack frame. You will get a different I/O pattern on the second mount. The first one is mounting something built by mkfs, the second one is doing some house keeping on log. That clear_stale_blocks code is there to ensure we do not have any old partial writes of log data from a failed previous mount scattered ahead of the log. It is writing zeros down into this space - this happens on every xfs mount after the first one. Your stack appears to have lost a couple of levels of calls, there is a pagebuf_iorequest in there. This is locking the pages in the I/O and sending them down to the lower layers. So xfs_mount does call xfs_readsb which does locking on the superblock buffer, but it xfs_readsb does not call xfs_mountfs, xfs_mount calls xfs_mountfs. In this case we are reusing the same buffer to write out several chunks of log data. In theory each write is completed before the second one is started - and we obtain the lock on the pagebuf before we go and reuse it again. To hang on a page lock like this, suggests that something went wrong at I/O completion time for the previous write. > > Second: has anyone looked at _pagebuf_page_io()? > > Is this fn expected to always unlock the page? > Maybe this is why we are getting bug 182 when > using chunk-size > page_size? > > That is, shouldn't this locking be like (not real C code): > > do_io_page(pg) > { > if (locking) > lock_page(pg); > do_io(pg); > if (locking) > unlock_page(pg); > } > > And in this way this locking will be out of the low-level > io fn. > > Also, what is the purpose of pb_locked? If this is _any_ kind > of lock, should it be atomic, bitops, or at least volatile? pb_locked just means the pages are already locked. The reason the code looks so complex is that it is attempting to map variable sized units of I/O (pagebufs) onto fixed sized units - pages and buffer heads. There is one common case in the code where we are creating a pagebuf for the first time where the locking of the pages has already been done once and we keep them locked until we read them in. > > I'm seeing this locking scattered all over pagebuf/ and have been > wondering if it should be pulled out like the example above? > Trust me, lots of eyes have spent lots of time in this code. Not sure what is going on here yet though. Steve > Sorry for the dumb questions, but I have only been looking at > the code for a couple of days and am trying to get this working... > > -- > Luben > From owner-linux-xfs@oss.sgi.com Fri Oct 25 06:19:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 06:19:49 -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 g9PDJguR032283 for ; Fri, 25 Oct 2002 06:19:44 -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 g9PDJk712801; Fri, 25 Oct 2002 15:19:47 +0200 (MEST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 1854NO-0004Ua-00; Fri, 25 Oct 2002 15:19:46 +0200 Date: Fri, 25 Oct 2002 15:19:46 +0200 From: christian.guggenberger@physik.uni-regensburg.de To: Luben Tuikov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs locking -- stack dump Message-ID: <20021025131946.GB16970@pc9391.physik.uni-regensburg.de> References: <3DB92CAF.775874FA@splentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB92CAF.775874FA@splentec.com> User-Agent: Mutt/1.3.28i X-archive-position: 1274 X-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 just curios, why are using lvm-1.1rc2? I thought the 1.1 series are very buggy and abandoned? I've read this some time ago on the lvm Homepage but for now I can't find that article again... Christian From owner-linux-xfs@oss.sgi.com Fri Oct 25 06:41:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 06:41:23 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PDfKuR000378 for ; Fri, 25 Oct 2002 06:41:20 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9PDfSf26771; Fri, 25 Oct 2002 09:41:28 -0400 Message-ID: <3DB94A0A.6DF8D5CA@splentec.com> Date: Fri, 25 Oct 2002 09:41:30 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: christian.guggenberger@physik.uni-regensburg.de CC: linux-xfs@oss.sgi.com Subject: Re: xfs locking -- stack dump References: <3DB92CAF.775874FA@splentec.com> <20021025131946.GB16970@pc9391.physik.uni-regensburg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs christian.guggenberger@physik.uni-regensburg.de wrote: > > just curios, why are using lvm-1.1rc2? > > I thought the 1.1 series are very buggy and abandoned? > I've read this some time ago on the lvm Homepage but for now I can't find > that article again... Which one should I use? The default with the kernel (2.4.19) or lvm-2.1.95.10 or lvm-2.0-{latest or beta}? -- Luben From owner-linux-xfs@oss.sgi.com Fri Oct 25 06:43:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 06:43:33 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm3.tiscalinet.be [212.35.2.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PDhTuR000846 for ; Fri, 25 Oct 2002 06:43:30 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscali) id 1854F0-0006H8-00; Fri, 25 Oct 2002 15:11:06 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Fri, 25 Oct 2002 15:10:56 +0200 Date: Fri, 25 Oct 2002 15:10:56 +0200 Message-ID: <3DB5776100000BC8@ocpmta8.be.tiscali.com> In-Reply-To: <20021025015459.GD687@frodo> From: jsoe0708@tiscali.be Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa To: "Nathan Scott" Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs Hi Nathan, >This ioctl is called from in cmd/xfsprogs/libxfs/init.c::findsize >so that's probably a good place to start debugging. > This was the right place. ANy way I prety sure that I found a small bug at this place. Here is my full patch: --- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200 +++ cmd/xfsprogs/libxfs/init.c 2002-10-25 14:22:34.000000000 +0200 @@ -155,11 +155,14 @@ progname, path, strerror(errno)); exit(1); } +#if !defined(__hppa__) || defined(__LP64__) error = ioctl(fd, BLKGETSIZE64, &size); - if (error >= 0) { + if (!error) { /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */ size = size >> 9; - } else { + } else +#endif + { /* If BLKGETSIZE64 fails, try BLKGETSIZE */ unsigned long tmpsize; error = ioctl(fd, BLKGETSIZE, &tmpsize); AFAIK ioctl return error = 0 if success and error >0 if fault. So at least lines 6 and 7 should be applied? Thanks again for relevant advise, Joel From owner-linux-xfs@oss.sgi.com Fri Oct 25 06:57:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 06:57:32 -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 g9PDvTuR001357 for ; Fri, 25 Oct 2002 06:57:29 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA24196; Fri, 25 Oct 2002 08:57:40 -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 IAA33906; Fri, 25 Oct 2002 08:57:39 -0500 (CDT) Date: Fri, 25 Oct 2002 08:52:51 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Eyal Lebedinsky cc: linux-xfs list Subject: Re: "Corruption of in-memory data detected" In-Reply-To: <3DB9232C.9C6099EB@eyal.emu.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1277 X-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 this problem is somewhat repeatable, there are a couple things we can try to get more information. Although, if it's in production, maybe that's not possible? -Eric On Fri, 25 Oct 2002, Eyal Lebedinsky wrote: > This is at the office. An SMP (2xAthlon MP 2000) machine with > 1GB memory. > > The fs is exported via NFA and it was forced down when a user > (on another machine) was deleting files off NFS. > > The kernel was build from CVS (linux-2.4-xfs) as of last > weekend (19/20 Oct). We dropped back to a version a few > months old which was used well on another, similar machine. > > > =========================== > xfs_force_shutdown(sd(8,0),0x8) called from line 1042 of file > xfs_trans.c. Return address = 0xf88ddfb7 > Corruption of in-memory data detected. Shutting down filesystem: > sd(8,0) > Please umount the filesystem, and rectify the problem(s) > =========================== > > > The system mounted OK after a reboot. Should I check or > fix the fs now? > > -- > Eyal Lebedinsky (eyal@eyal.emu.id.au) > > From owner-linux-xfs@oss.sgi.com Fri Oct 25 07:13:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 07:13:35 -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 g9PEDSuR001964 for ; Fri, 25 Oct 2002 07:13:28 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA87712; Fri, 25 Oct 2002 09:13:33 -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 JAA99144; Fri, 25 Oct 2002 09:13:32 -0500 (CDT) Date: Fri, 25 Oct 2002 09:08:45 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: jsoe0708@tiscali.be cc: Nathan Scott , Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa In-Reply-To: <3DB5776100000BC8@ocpmta8.be.tiscali.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1278 X-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, thanks for looking into it. I originally handled the error as I did because per the ioctl man page, RETURN VALUE Usually, on success zero is returned. A few ioctls use the return value as an output parameter and return a nonnegative value on success. On error, -1 is returned, and errno is set appropriately. So, I treated error >= 0 as success. So, it looks like BLKGETSIZE64 -is- failing* for you, and your patch below is really a workaround for this. It might be good to find out why the ioctl is failing (which is really not an xfs problem per se) What kind of device are you trying to mkfs on? -Eric *actually, it's succeeding, but returning bad data. On Fri, 25 Oct 2002 jsoe0708@tiscali.be wrote: > ANy way I prety sure that I found a small bug at this place. > > Here is my full patch: > --- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200 > +++ cmd/xfsprogs/libxfs/init.c 2002-10-25 14:22:34.000000000 +0200 > @@ -155,11 +155,14 @@ > progname, path, strerror(errno)); > exit(1); > } > +#if !defined(__hppa__) || defined(__LP64__) > error = ioctl(fd, BLKGETSIZE64, &size); > - if (error >= 0) { > + if (!error) { > /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */ > size = size >> 9; > - } else { > + } else > +#endif > + { > /* If BLKGETSIZE64 fails, try BLKGETSIZE */ > unsigned long tmpsize; > error = ioctl(fd, BLKGETSIZE, &tmpsize); > > AFAIK ioctl return error = 0 if success and error >0 if fault. So at least > lines 6 and 7 should be applied? > > Thanks again for relevant advise, > Joel > > From owner-linux-xfs@oss.sgi.com Fri Oct 25 07:57:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 07:57:32 -0700 (PDT) Received: from smtp-out.tiscali.be (spoolm6.tiscalinet.be [212.35.2.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PEvTuR004303 for ; Fri, 25 Oct 2002 07:57:30 -0700 Received: from [62.235.14.106] (helo=mail.tiscali.be) by smtp-out.tiscali.be with esmtp (Tiscali) id 1855uA-0002XV-00; Fri, 25 Oct 2002 16:57:42 +0200 Received: from [193.75.200.4] by mail.tiscali.be with HTTP; Fri, 25 Oct 2002 16:57:32 +0200 Date: Fri, 25 Oct 2002 16:57:32 +0200 Message-ID: <3DB5776100000C2E@ocpmta8.be.tiscali.com> In-Reply-To: From: jsoe0708@tiscali.be Subject: Re: XFS (CVS release) problem: mkfs.xfs failed on hppa To: "Eric Sandeen" Cc: "Nathan Scott" , linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jsoe0708@tiscali.be Precedence: bulk X-list: linux-xfs Hi Eric, > >Hi, thanks for looking into it. > >I originally handled the error as I did because per the ioctl man page, > >RETURN VALUE > Usually, on success zero is returned. A few ioctls use the > return value as an output parameter and return a nonnegative > value on success. On error, -1 is returned, and > errno is set appropriately. > >So, I treated error >= 0 as success. Ah, that is me who is bad [Thanks for advise]. > >So, it looks like BLKGETSIZE64 -is- failing* for you, and your patch below >is really a workaround for this. It might be good to find out why >the ioctl is failing (which is really not an xfs problem per se) > It actually failed for 32bits release of hppa kernel because BLKGETSIZE64 is not yet implemented; in that case (see linux/include/asm-parisc/uaccess.h) the kernel printk a BUG message (see syslog) without returning error code (this should be -1 and not EFAULT as I wrongly assume :( ) >What kind of device are you trying to mkfs on? > Firstly on a simple slice of a scsi disk (It seems to works fine with mentionned workaround) Just still have to test over an evms lvm (which seems also supported as I read on your ml and code :) ) Thanks again for attention and adivses (just still have to review a hppa kernel patch) Joel From owner-linux-xfs@oss.sgi.com Fri Oct 25 08:06:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 08:06:27 -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 g9PF6KuR004879 for ; Fri, 25 Oct 2002 08:06:21 -0700 Received: from pinatubo.mpc.local ([172.16.15.3]) by moving-picture.com with smtp (Exim 3.22 #1) id 18562h-0004Sm-00 for linux-xfs@oss.sgi.com; Fri, 25 Oct 2002 16:06:31 +0100 Date: Fri, 25 Oct 2002 16:06:31 +0100 From: Huw Lynes To: linux-xfs@oss.sgi.com Subject: Kernel Oops on 2.4.18 xfs-1.1 Message-Id: <20021025160631.1080c4ae.huw-l@moving-picture.com> In-Reply-To: <20021001072627.A218954@wobbly.melbourne.sgi.com> References: <1033336748.1088.4.camel@laptop.americas.sgi.com> <20021001072627.A218954@wobbly.melbourne.sgi.com> Organization: The Moving Picture Company X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; ) Mime-Version: 1.0 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: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: huw-l@moving-picture.com Precedence: bulk X-list: linux-xfs One of our production XFS servers went down today. The symptoms it was exhibiting were that disk access stopped causing load-average to climb. It came back after a reboot and seems to be running fine now. Any advice gratefully received. The Oops and stack-trace follow: Oct 25 14:44:24 clark kernel: Call Trace: [xfs_alloc_lookup_ge+32/40] [xfs_alloc _ag_vextent_near+93/2628] [xfs_alloc_ag_vextent+54/232] [xfs_alloc_vextent+910/1 084] [xfs_bmap_alloc+8066/8960] Oct 25 14:44:24 clark kernel: Call Trace: [] [] [] [] [] Oct 25 14:44:24 clark kernel: [] [] [] [] [] [] Oct 25 14:44:24 clark kernel: [] [] [] [] [] [] Oct 25 14:44:24 clark kernel: [] [] [] [] [] [] Oct 25 14:44:24 clark kernel: [] [] [] [] [] [] Oct 25 14:44:24 clark kernel: [] Oct 25 14:44:24 clark kernel: Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8 >>EIP; c0176fe9 <===== Trace; c0178b68 Trace; c017364d Trace; c01733c6 Trace; c017573e Trace; c018533e Trace; c01ce929 Trace; c01912e3 Trace; c01912e3 Trace; c0187703 Trace; c01893d9 Trace; c01d6878 Trace; c01b55bf Trace; c01d86e4 Trace; c01d6878 Trace; c013dbff Trace; c0132271 Trace; c0132b80 Trace; c01d68fc Trace; c01d6878 Trace; c01d2c21 Trace; c01d1d27 Trace; c01d6878 Trace; c01d6adf Trace; c01d6878 Trace; c013a849 Trace; c013aa3c Trace; c01167e6 Trace; c013e014 Trace; c0105000 <_stext+0/0> Trace; c01057db Code; c0176fe9 00000000 <_EIP>: Code; c0176fe9 <===== 0: 8b 52 30 mov 0x30(%edx),%edx <===== Code; c0176fec 3: 89 54 24 58 mov %edx,0x58(%esp,1) Code; c0176ff0 7: 51 push %ecx Code; c0176ff1 8: 55 push %ebp Code; c0176ff2 9: 8b 44 24 60 mov 0x60(%esp,1),%eax Code; c0176ff6 d: 50 push %eax Code; c0176ff7 e: 8b 54 24 78 mov 0x78(%esp,1),%edx Code; c0176ffb 12: 52 push %edx Code; c0176ffc 13: e8 00 00 00 00 call 18 <_EIP+0x18> c0177001 -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From owner-linux-xfs@oss.sgi.com Fri Oct 25 08:26:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 08:26:12 -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 g9PFQ9uR005620 for ; Fri, 25 Oct 2002 08:26:10 -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 g9PFQM706194; Fri, 25 Oct 2002 17:26:23 +0200 (MEST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 1856Lu-0005G2-00; Fri, 25 Oct 2002 17:26:22 +0200 Date: Fri, 25 Oct 2002 17:26:22 +0200 From: christian.guggenberger@physik.uni-regensburg.de To: Luben Tuikov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs locking -- stack dump Message-ID: <20021025152622.GA19831@pc9391.physik.uni-regensburg.de> References: <3DB92CAF.775874FA@splentec.com> <20021025131946.GB16970@pc9391.physik.uni-regensburg.de> <3DB94A0A.6DF8D5CA@splentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB94A0A.6DF8D5CA@splentec.com> User-Agent: Mutt/1.3.28i X-archive-position: 1281 X-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 Fri, Oct 25, 2002 at 09:41:30AM -0400, Luben Tuikov wrote: > christian.guggenberger@physik.uni-regensburg.de wrote: > > > > just curios, why are using lvm-1.1rc2? > > > > I thought the 1.1 series are very buggy and abandoned? > > I've read this some time ago on the lvm Homepage but for now I can't find > > that article again... > > Which one should I use? The default with the kernel (2.4.19) > or lvm-2.1.95.10 or lvm-2.0-{latest or beta}? > > hmmm, personally I can't say anything about lvm2(any version) cause I've never had tried it. I don't use lvm heavily, so .... Maybe a good starting point would be the 1.0.5 release (the source code provides some advice how to create a patch against your kernel, as lvm in 2.4.19 is version 1.0.3). I'll try to find that article I talked about in my previous mail. We're using lvm-1.0.4 userland tools (debian package) and pure CVS XFS kernels. Maybe evms would be a look worth, too, but I've also have no experiences with it. Some insights by others are very welcome! Christian From owner-linux-xfs@oss.sgi.com Fri Oct 25 09:54:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 09:54:35 -0700 (PDT) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PGsVuR009173 for ; Fri, 25 Oct 2002 09:54:31 -0700 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9PGsef31009; Fri, 25 Oct 2002 12:54:40 -0400 Message-ID: <3DB97752.EBA18F0F@splentec.com> Date: Fri, 25 Oct 2002 12:54:42 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs , linux-lvm Subject: Recent dissections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs As the folks on linux-xfs know, I've recently tried to get xfs on top of lvm on top of raid5 on top of some scsi disks to work. Here are some recent curiosities which for now seem to reconcile mount-s in D and BUG() in unlock_page(): Here is the basic framework: FS --> LVM --> md(raid5) --> scsi disks (1) when FS = ext2, the above set up works alright, when FS = xfs, then as you know either mount would sleep indefinitely on down(), or BUG() in unlock_page(). I've written a tiny SCSI simulator driver for block devices (non-SCSI; unrelated to all this), lets call it ``sbs''. Strangely when the above set up is like so: xfs --> LVM --> sbs --> md(raid5) --> scsi disks (2) then everything works all right. The only way I can explain this, is that the transformation that bh's get along the way down and up somehow confuse xfs in setup (1), (remember ext2 works all right in (1)), but when sbs is in between LVM and md then things are ok for xfs. This ``solution'', was prompted by other curiosities we found out here, like when either md or LVM was missing from (1) with xfs, then things worked ok. So, to make everyone happy, we put sbs in the middle of LVM and md (see (2)), so that from xfs's point of view it looks like LVM is talking to a scsi block device, and from md's point of view it looks like it (md) is getting its bh's from the linux block layer. I hope those curiosities help ppl get some/any clue(s) as to what could be happening and resolve this -- especially those who know what fs/xfs/pagebuf/*.c is all about... Bh's transformation, collecting them back into a page in xfs from xx_end_io(), etc... where could it be? -- Luben P.S. No sensible performance penalties for putting sbs in the middle. But that's irrelevant. From owner-linux-xfs@oss.sgi.com Fri Oct 25 10:12:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 10:12:35 -0700 (PDT) Received: from morpheus.matrix.com (213-99-179-23.uc.nombres.ttd.es [213.99.179.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PHCMuR009800 for ; Fri, 25 Oct 2002 10:12:23 -0700 Received: (qmail 21444 invoked by uid 1000); 25 Oct 2002 17:13:45 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 19:13:44 +0200 To: linux-xfs Subject: Re: About removing files Message-ID: <20021025171344.GA21159@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> <3DB92B1E.2010807@wgate.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <3DB92B1E.2010807@wgate.com> User-Agent: Mutt/1.4i X-archive-position: 1283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I never said that XFS is slower than other FS ;). I just said that it spent a lot of time to delete three files. Now I know a bit more about the utilities (xfs_bmap & xfs_fsr) and take more care with files by looking their extents. Sorry if I am a little heavy... When a file is downoaded from internet it is written to disk in small blocks, may it be a problem? See you, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uXvIWIvihXTx06wRAmZ/AKCylf+kBhVUamWv+lCLl1x3CPEE9gCdGCz0 KZ6mzS62uSCDFcqhhFWKDGM= =rqcR -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-linux-xfs@oss.sgi.com Fri Oct 25 10:25:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 10:25:42 -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 g9PHPauR010291 for ; Fri, 25 Oct 2002 10:25:37 -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 41A6KBTR; Fri, 25 Oct 2002 13:25:59 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g9PHPqM31855; Fri, 25 Oct 2002 13:25:52 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3DB97EA0.6030407@wgate.com> Date: Fri, 25 Oct 2002 13:25:52 -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: yoros@wanadoo.es CC: linux-xfs Subject: Re: About removing files References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> <3DB92B1E.2010807@wgate.com> <20021025171344.GA21159@morpheus.matrix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1284 X-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 yoros@wanadoo.es wrote: > I never said that XFS is slower than other FS ;). I just said that it > spent a lot of time to delete three files. Now I know a bit more about > the utilities (xfs_bmap & xfs_fsr) and take more care with files by > looking their extents. > > Sorry if I am a little heavy... > > When a file is downoaded from internet it is written to disk in small > blocks, may it be a problem? It depends on the speed of the download and the way in which the software does the file writes. XFS does some pre-allocation of disk space when you first open the file and as you write to it. This space is released as things get closed. I am not that sure of how this works anymore (my brain FIFO has looped a few times too many) -- 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 Fri Oct 25 11:13:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 11:13:57 -0700 (PDT) Received: from morpheus.matrix.com (213-99-179-23.uc.nombres.ttd.es [213.99.179.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PIDpuR011128 for ; Fri, 25 Oct 2002 11:13:53 -0700 Received: (qmail 21978 invoked by uid 1000); 25 Oct 2002 18:15:14 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 20:15:14 +0200 To: linux-xfs Subject: Here is the results of my last question... Message-ID: <20021025181514.GA21940@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As said in the subject, related to my other mails about removing files. I have experienced that using one downloader assistant (that creates a big sparse file an then fill it to complete download), I get a file with lots of extents sized from 24 to 80 blocks... Yes, I must run xfs_fsr after download, but it is interesant to include this performance to the core code... Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uYoyWIvihXTx06wRAnAeAKC9d9zETfNnQJ8UXEpj+aE0VKBNlgCgntDO Ka97qWxbnzShEyGdqZStu6U= =l/Dc -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-linux-xfs@oss.sgi.com Fri Oct 25 11:27:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 11:27:18 -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 g9PIRGuR011617 for ; Fri, 25 Oct 2002 11:27:16 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C7D1232237; Fri, 25 Oct 2002 20:27:27 +0200 (MEST) Date: Fri, 25 Oct 2002 20:27:27 +0200 From: Andi Kleen To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: Here is the results of my last question... Message-ID: <20021025202727.A2421@wotan.suse.de> References: <20021025181514.GA21940@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025181514.GA21940@morpheus.matrix.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1286 X-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 25, 2002 at 08:15:14PM +0200, yoros@wanadoo.es wrote: > > As said in the subject, related to my other mails about removing files. > > I have experienced that using one downloader assistant (that creates a > big sparse file an then fill it to complete download), I get a file with > lots of extents sized from 24 to 80 blocks... Yes, I must run xfs_fsr > after download, but it is interesant to include this performance to the > core code... The right thing would be to change the downloader assistant to use XFS' file preallocation ioctls so that it allocates the full space in advance. Unfortuately they are not fully implemented on linux/xfs and are only available for root currently. I would be possible to create the file first and fill it with zeroes. This way you should get few extents. -Andi From owner-linux-xfs@oss.sgi.com Fri Oct 25 12:21:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 12:21:49 -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 g9PJLguR015435 for ; Fri, 25 Oct 2002 12:21:42 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA08397; Fri, 25 Oct 2002 14:21:53 -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 OAA48047; Fri, 25 Oct 2002 14:21:52 -0500 (CDT) Subject: Re: Recent dissections From: Eric Sandeen To: Luben Tuikov Cc: linux-xfs , linux-lvm In-Reply-To: <3DB97752.EBA18F0F@splentec.com> References: <3DB97752.EBA18F0F@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 25 Oct 2002 14:17:02 -0500 Message-Id: <1035573423.25939.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1287 X-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 do special handling of LVM and md in xfs_super.c:xfs_alloc_buftarg(), (and page_buf.c:_pagebuf_page_io()) using only sector-sized buffer heads for pagebufs in the LVM case, and only aligned I/O in the md case. If you had xfs -> md -> lvm -> scsi, then I think this might explain your problem, since XFS thinks it's talking to md, when in fact there is LVM (more restrictive I/O) underneath it. However, you say that you have xfs -> lvm -> md -> scsi, so I am still confused... Just for fun, you could try always setting btp->pbr_flags = PBR_SECTOR_ONLY; in xfs_alloc_buftarg, and see if it makes a difference? -Eric On Fri, 2002-10-25 at 11:54, Luben Tuikov wrote: > As the folks on linux-xfs know, I've recently tried to > get xfs on top of lvm on top of raid5 on top of some > scsi disks to work. > > Here are some recent curiosities which for now seem > to reconcile mount-s in D and BUG() in unlock_page(): > > Here is the basic framework: > > FS --> LVM --> md(raid5) --> scsi disks (1) > > when FS = ext2, the above set up works alright, > when FS = xfs, then as you know either mount > would sleep indefinitely on down(), or BUG() in unlock_page(). > > I've written a tiny SCSI simulator driver for > block devices (non-SCSI; unrelated to all this), > lets call it ``sbs''. > > Strangely when the above set up is like so: > > xfs --> LVM --> sbs --> md(raid5) --> scsi disks (2) > > then everything works all right. > > The only way I can explain this, is that the transformation > that bh's get along the way down and up somehow confuse > xfs in setup (1), (remember ext2 works all right in (1)), > but when sbs is in between LVM and md then things are ok > for xfs. > > This ``solution'', was prompted by other curiosities we found > out here, like when either md or LVM was missing from (1) > with xfs, then things worked ok. > > So, to make everyone happy, we put sbs in the middle of > LVM and md (see (2)), so that from xfs's point of view > it looks like LVM is talking to a scsi block device, and > from md's point of view it looks like it (md) is getting > its bh's from the linux block layer. > > I hope those curiosities help ppl get some/any clue(s) > as to what could be happening and resolve this -- especially > those who know what fs/xfs/pagebuf/*.c is all about... > > Bh's transformation, collecting them back into a page in > xfs from xx_end_io(), etc... where could it be? > > -- > Luben > > P.S. No sensible performance penalties for putting sbs in > the middle. But that's irrelevant. > -- 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 25 12:35:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 12:35:27 -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 g9PJZPuR016835 for ; Fri, 25 Oct 2002 12:35:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA93597; Fri, 25 Oct 2002 14:35:37 -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 OAA23243; Fri, 25 Oct 2002 14:35:36 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9PJVQk06379; Fri, 25 Oct 2002 14:31:26 -0500 Subject: Re: About removing files From: Steve Lord To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021025171344.GA21159@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> <3DB92B1E.2010807@wgate.com> <20021025171344.GA21159@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Oct 2002 14:31:26 -0500 Message-Id: <1035574286.6337.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1288 X-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-25 at 12:13, yoros@wanadoo.es wrote: > > I never said that XFS is slower than other FS ;). I just said that it > spent a lot of time to delete three files. Now I know a bit more about > the utilities (xfs_bmap & xfs_fsr) and take more care with files by > looking their extents. > > Sorry if I am a little heavy... > > When a file is downoaded from internet it is written to disk in small > blocks, may it be a problem? > If the download program is actually downloading multiple sections of the file in parallel to different offsets then there may be issues getting reasonable allocation. Another possibility is you are actually downloading several files in parallel to the same directory. Flush activity during these downloads would tend to scatter the extents of the individual files around. 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 25 12:48:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 12:48:56 -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 g9PJmsuR018625 for ; Fri, 25 Oct 2002 12:48:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 0AEC91EDF7C; Fri, 25 Oct 2002 12:49:12 -0700 (PDT) Date: Fri, 25 Oct 2002 12:49:11 -0700 From: Chris Wedgwood To: Andi Kleen Cc: yoros@wanadoo.es, linux-xfs Subject: Re: Here is the results of my last question... Message-ID: <20021025194911.GB26998@tapu.f00f.org> References: <20021025181514.GA21940@morpheus.matrix.com> <20021025202727.A2421@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025202727.A2421@wotan.suse.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1289 X-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 25, 2002 at 08:27:27PM +0200, Andi Kleen wrote: > The right thing would be to change the downloader assistant to use > XFS' file preallocation ioctls so that it allocates the full space > in advance. Unfortuately they are not fully implemented on linux/xfs > and are only available for root currently. I would be possible to > create the file first and fill it with zeroes. This way you should > get few extents. It would be pretty cheap for the downloader to actually just touch lseek/touch ahead a few MB of each writer too, this would be almost as easy to code and would work on other filesystems. --cw From owner-linux-xfs@oss.sgi.com Fri Oct 25 12:58:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 12:58:52 -0700 (PDT) Received: from morpheus.matrix.com (213-99-179-23.uc.nombres.ttd.es [213.99.179.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PJwguR021588 for ; Fri, 25 Oct 2002 12:58:43 -0700 Received: (qmail 22473 invoked by uid 1000); 25 Oct 2002 20:00:06 -0000 From: yoros@wanadoo.es Date: Fri, 25 Oct 2002 22:00:06 +0200 To: linux-xfs Subject: Re: About removing files Message-ID: <20021025200006.GA22371@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> <3DB92B1E.2010807@wgate.com> <20021025171344.GA21159@morpheus.matrix.com> <1035574286.6337.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <1035574286.6337.4.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 25, 2002 at 02:31:26PM -0500, Steve Lord wrote: > On Fri, 2002-10-25 at 12:13, yoros@wanadoo.es wrote: > >=20 > > I never said that XFS is slower than other FS ;). I just said that it > > spent a lot of time to delete three files. Now I know a bit more about > > the utilities (xfs_bmap & xfs_fsr) and take more care with files by > > looking their extents. > >=20 > > Sorry if I am a little heavy... > >=20 > > When a file is downoaded from internet it is written to disk in small > > blocks, may it be a problem? > >=20 >=20 > If the download program is actually downloading multiple sections > of the file in parallel to different offsets then there may be > issues getting reasonable allocation. >=20 > Another possibility is you are actually downloading several files > in parallel to the same directory. Flush activity during these > downloads would tend to scatter the extents of the individual > files around. I think it happends the second situation. Yes, I am downloading more than one file to the same directory (downloads directory :) and I obtain that results. Seen this results I am thinking about the creation of a sparse file. Creating sparse files, helps files to be fragmented? (sorry, making a complex questions is hard to me). Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9uaLGWIvihXTx06wRAssBAJ0c3kdfP+YdWjoP1jPzwWp/ZxKWkwCgwf0o c+HqoB1+Vj6WmdS5W8PL4Ys= =TBdY -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-linux-xfs@oss.sgi.com Fri Oct 25 13:18:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 13:18:58 -0700 (PDT) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PKItuR022199 for ; Fri, 25 Oct 2002 13:18:55 -0700 content-class: urn:content-classes:message Subject: RE: Share suddenly empty MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 25 Oct 2002 16:16:23 -0400 Message-ID: <5A2E4FE5C3D6544D94403072129E30D903A169@cli_exch_one.complexlit.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Share suddenly empty Thread-Index: AcJ6208cqmks0UPRRAa844JJl1Cu4QBh3AUw From: "Brian Gulizia" To: "Seth Mos" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9PKItuR022202 X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Wonderful. xfs_repair cant/wont finish due to the piece of crap array that it is trying to repair...which is an Arena Indy 2400. It gets all the way to phase 5 then a message flashes on the screen of the raid array that says "cmd buf empty!" which I'm told by the manufacturer means that the buffer is full and cant/wont accept any more commands. I don't know if this is because it did so much before phase 5 or if it is just phase 5 that does it. I don't suppose there is some way to run the xfs_repair one phase at a time? Incidently, I ran a # dd if=/dev/sdb bs=512 count=1 |hexdump as mentioned in another post and everything seems to look fine there. -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Wednesday, October 23, 2002 5:30 PM To: Brian Gulizia Cc: linux-xfs@oss.sgi.com Subject: RE: Share suddenly empty On Wed, 23 Oct 2002, Brian Gulizia wrote: > I hadnt done anything to it. All I did was reboot, I got the "not a valid block > device" when i tried to mout it, rebooted again and was able to mount it but it has > nothing on it when I do an ls. You'll have to excuse my newbieness, but when you > say let the filesystem do recovery, what do you mean? I didnt see anything about the > kernel doing any recovering. The recovery part is something the filesystem does after a "unclean unmount" eg. poweroff. When you mount the filesystem it would be done automatically. If recovery was required there will be a message during the mount of the filesystem. And if I am right there should at least be a message in you /var/log/messages (or equivalent) stating that there was a filesystem error. If not from the just attempted mount there should at least be one from when the files first "dissappeard". Did you already repair the filesystem per chance? Check with mount if it is unmounted. xfs_repair -n /dev/sdb? or xfs_check /dev/sdb? and check for errors or other problems it finds. Mail that back to the list (zipped please). If there is nothing serious in there you could attempt a repair of the filesystem if you are couragesous ;-) I'm going to bed here, maybe someone from america can pick this up *hint* See you in 8 hours. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Oct 25 13:18:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 13:18:59 -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 g9PKIruR022201 for ; Fri, 25 Oct 2002 13:18:55 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 3D82A1EDF90; Fri, 25 Oct 2002 13:19:11 -0700 (PDT) Date: Fri, 25 Oct 2002 13:19:11 -0700 From: Chris Wedgwood To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: About removing files Message-ID: <20021025201911.GA27331@tapu.f00f.org> References: <20021024220639.GA20279@morpheus.matrix.com> <1035497418.31455.13.camel@jen.americas.sgi.com> <20021024225614.GA20660@morpheus.matrix.com> <20021024231656.GA19254@tapu.f00f.org> <20021025051820.GA22414@morpheus.matrix.com> <3DB92B1E.2010807@wgate.com> <20021025171344.GA21159@morpheus.matrix.com> <1035574286.6337.4.camel@jen.americas.sgi.com> <20021025200006.GA22371@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025200006.GA22371@morpheus.matrix.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1292 X-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 25, 2002 at 10:00:06PM +0200, yoros@wanadoo.es wrote: > I think it happends the second situation. Yes, I am downloading more > than one file to the same directory (downloads directory :) and I > obtain that results. How many files at once and how fast do they download? > Seen this results I am thinking about the creation of a sparse file. What application are we talking about here? > Creating sparse files, helps files to be fragmented? (sorry, making > a complex questions is hard to me). Sparse files are fragmented almost by defintion ... sparse files have holes in them ... and having holes pretty much means you end up with discontiguous regions of data (the two exceptions here are hole-at-start and hole-at-end). --cw From owner-linux-xfs@oss.sgi.com Fri Oct 25 13:38:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 13:38:22 -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 g9PKc7uR023256 for ; Fri, 25 Oct 2002 13:38: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 NAA04735 for ; Fri, 25 Oct 2002 13:38:24 -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 g9PKbJdp007629 for ; Fri, 25 Oct 2002 22:37:19 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9PKbJlb007628 for linux-xfs@oss.sgi.com; Fri, 25 Oct 2002 22:37:19 +0200 Date: Fri, 25 Oct 2002 22:37:19 +0200 Message-Id: <200210252037.g9PKbJlb007628@lab343.munich.sgi.com> Subject: TAKE - remove indoe reference cache To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 1293 X-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 In 2.5 the nfsd has been changed to keep dentries on a LRU list after use, this means the reference on the inode does not go away imediately. This allows us to get rid of the inode reference cache in XFS. Date: Fri Oct 25 13:35:44 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:131130a linux/fs/xfs/xfs_rw.h - 1.70 linux/fs/xfs/xfs_rw.c - 1.371 - remove inode refcache linux/fs/xfs/xfs_vnodeops.c - 1.570 linux/fs/xfs/xfs_vfsops.c - 1.390 - don't call into inode refcache linux/fs/xfs/xfs_mount.h - 1.160 - remove refcache-related fields from struct xfs_mount linux/fs/xfs/xfs_mount.c - 1.310 - don't call into inode refcache linux/fs/xfs/xfs_inode.h - 1.174 - remove refcache-related fields from struct xfs_inode linux/fs/xfs/xfs_fsops.c - 1.87 linux/fs/xfs/xfs_rename.c - 1.42 linux/fs/xfs/linux/xfs_lrw.c - 1.174 - don't call into inode refcache linux/fs/xfs/linux/xfs_sysctl.h - 1.7 linux/fs/xfs/linux/xfs_sysctl.c - 1.10 - remove inode refcache-related sysctls. From owner-linux-xfs@oss.sgi.com Fri Oct 25 17:08:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 17:09:03 -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 g9Q08wuR025577 for ; Fri, 25 Oct 2002 17:08:58 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 222D52FF0B for ; Fri, 25 Oct 2002 17:09:16 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id CDC8E2FF0B for ; Fri, 25 Oct 2002 17:09:14 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 3C0501967B for ; Fri, 25 Oct 2002 17:09:04 -0700 (PDT) Subject: Re: RedHat 8.0 Installer From: Florin Andrei To: linux-xfs In-Reply-To: <3413.206.153.21.5.1035412914.squirrel@mail.ccdmerchandise.com> References: <3413.206.153.21.5.1035412914.squirrel@mail.ccdmerchandise.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 25 Oct 2002 17:09:04 -0700 Message-Id: <1035590944.10524.101.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1294 X-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 Wed, 2002-10-23 at 15:41, Doug Eubanks wrote: > > Is anyone using the Release-1.2pre1 RedHat Installer in production? I > have been using the installers for quite a while now and I need to redo a > server (that gets quite a bit of load) and I HATE EXT3. I was hoping to > get some feedback from someone who has used this version with RH8 If you don't really need XFS on the root partition, you might as well use the original RH installer, create just /boot, the swap and a small root partition (say, 1GB or depending on your system needs) and leave the rest unpartitioned. Install the OS, then get the kernel RPMs and utilities from oss.sgi.com, install them, boot the new kernel, create and format the XFS partitions, and you're done. I did this experiment, it works without any problems. And usually you're not concerned with the root partition, since the real work is always done someplace else. ;-) I subscribe to what Chris Tooley said. RH 8.0 is a major change, so potentially some things might get broken after the upgrade. Therefore, you have to do three things before proceeding: test, test and test. For mission-critical apps you may want to be as conservative as you can. On the other hand, performance-wise, 8.0 brings an unexpected but very welcome leap: the machine simply feels a lot faster under multiple concurrent CPU-intensive tasks. Could be the HZ=512 thing in the kernel, could be the newer gcc and glibc, could be a combination of these and/or more. Anyway, for example, while running transcode (a versatile, threaded video encoder/decoder) on RH7.3 to convert a stream from MPEG2 to DivX, the desktop was sluggish, the mouse felt like "pushing through molasses" and the big applications (Evolution, Gimp) were generally slow (no wonder, 'cause transcode is typically running several threads on my single-CPU machine, each thread taking care of a video operation: resize, clip, codec conversion, etc.). But use the same software on 8.0 and do the same tasks, and you almost can't tell there's a CPU hog on your system anymore. Well, almost. I also suspect that the applications that do a lot of stuff in a big select() loop (i.e. Squid) might see a significant performance boost. And i expect improvements for machines running lots of processes simultaneously. I didn't run real benchmarks though, so take my words with the recommanded grain of salt. It might be interesting to see more tests with XFS and RH 8.0. The environment definitely feels different (and i'm not talking here about the desktop ;-) ). -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) From owner-linux-xfs@oss.sgi.com Fri Oct 25 17:15:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 17:15:08 -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 g9Q0F2uR026029 for ; Fri, 25 Oct 2002 17:15:02 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 376782FF0B for ; Fri, 25 Oct 2002 17:15:20 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 8BE0E2FF0B for ; Fri, 25 Oct 2002 17:15:19 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 300F01967B for ; Fri, 25 Oct 2002 17:15:09 -0700 (PDT) Subject: Re: About removing files From: Florin Andrei To: linux-xfs In-Reply-To: <20021024220639.GA20279@morpheus.matrix.com> References: <20021024220639.GA20279@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 25 Oct 2002 17:15:09 -0700 Message-Id: <1035591309.10210.107.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1295 X-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 Thu, 2002-10-24 at 15:06, yoros@wanadoo.es wrote: > > I have experienced large times when deleting a few big files (they were > ISO images). Why do XFS waste such time for deleting that files? > > Note: It happends to me a lot of times... Process: I make, record and > finally delete the ISO image. This is intriguing. My experience is that XFS is _always_ faster when dealing with large files (create, write, read, delete). It might be slightly slower with lots of small files, but not with a few large ones. Perhaps your filesystem is terribly fragmented. -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) From owner-linux-xfs@oss.sgi.com Fri Oct 25 18:05:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 18:05: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 g9Q15kuR026806 for ; Fri, 25 Oct 2002 18:05:46 -0700 Received: (qmail 36733 invoked from network); 26 Oct 2002 01:05:54 -0000 Received: from 202-6-128-143.ip.adam.com.au (HELO linux.david.net.au) (202.6.128.143) by eden.adam.com.au with SMTP; 26 Oct 2002 01:05:54 -0000 Date: Sat, 26 Oct 2002 10:51:31 +0930 From: David Lloyd To: linux-xfs@oss.sgi.com Subject: XFS Logs on Another Device Message-Id: <20021026105131.6d692c0d.lloy0076@adam.com.au> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1296 X-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 I can't quite work out how to get XFS to put the logs on another device or volume. A few questions: 1) How does one setup the other device? - does it need a separate partition - or...? 2) What would a mkfs.xfs look like for this situation? - could one alter an existing partition to use an external log 3) What would happen if the other device went down but the main device didn't? DSL -- The Linux C Programming Lists: * http://lists.linux.org.au/listinfo/linuxcprogramming/ The Linux C++ Programming Lists: * http://lists.linux.org.au/listinfo/tuxcpprogramming/ From owner-linux-xfs@oss.sgi.com Fri Oct 25 19:28:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Oct 2002 19:28:21 -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 g9Q2SJuR027656 for ; Fri, 25 Oct 2002 19:28:19 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA33209; Fri, 25 Oct 2002 21:28:32 -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 VAA04646; Fri, 25 Oct 2002 21:28:31 -0500 (CDT) Date: Fri, 25 Oct 2002 21:23:38 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: David Lloyd cc: linux-xfs@oss.sgi.com Subject: Re: XFS Logs on Another Device In-Reply-To: <20021026105131.6d692c0d.lloy0076@adam.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1297 X-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 Sat, 26 Oct 2002, David Lloyd wrote: > > I can't quite work out how to get XFS to put the logs on another device > or volume. A few questions: > > 1) How does one setup the other device? > - does it need a separate partition > - or...? Yes, the external log needs it's own partition, on any disk. I suppose a whole disk might work, but that would be a horrible waste of space. :) > 2) What would a mkfs.xfs look like for this situation? > - could one alter an existing partition to use an external log Well, from the man page.... ;-) The metadata log can be placed on another device to reduce the number of disk seeks. To create a filesystem on the first partition on the first SCSI disk with a 10000 block log located on the first partition on the second SCSI disk, use: mkfs.xfs -l logdev=/dev/sdb1,size=10000b /dev/sda1 It's technically possible to alter an existing internal-log fs to use an external log, but it's neither automatic nor supported. > 3) What would happen if the other device went down but the main device > didn't? Your next log write would fail, and the filesystem would shut down. You'd also have a slightly inconsistent fs, but in general you could recover from it. -Eric > > -- > The Linux C Programming Lists: > * http://lists.linux.org.au/listinfo/linuxcprogramming/ > The Linux C++ Programming Lists: > * http://lists.linux.org.au/listinfo/tuxcpprogramming/ > > From owner-linux-xfs@oss.sgi.com Sat Oct 26 00:37:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 00:37:06 -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 g9Q7b1uR030823 for ; Sat, 26 Oct 2002 00:37:02 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9Q7bCus087699; Sat, 26 Oct 2002 09:37:13 +0200 (CEST) Message-Id: <4.3.2.7.2.20021026093125.03ec53f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Oct 2002 09:35:56 +0200 To: "Brian Gulizia" , From: Seth Mos Subject: RE: Share suddenly empty Cc: In-Reply-To: <5A2E4FE5C3D6544D94403072129E30D903A169@cli_exch_one.comple xlit.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 16:16 25-10-2002 -0400, Brian Gulizia wrote: >Wonderful. > >xfs_repair cant/wont finish due to the piece of crap array that it is >trying to >repair...which is an Arena Indy 2400. It gets all the way to phase 5 then >a message >flashes on the screen of the raid array that says "cmd buf empty!" which >I'm told by the >manufacturer means that the buffer is full and cant/wont accept any more >commands. My best guess is that the scsi driver is putting more scatter gather entries in the queue then the host (arena) can handle. You can adjust the length of the scsi command queue in the driver. I don't know if you can change it on the fly, but you can define this during compile time for some of the scsi adapters. >I don't know if this is because it did so much before phase 5 or if it is >just phase 5 that does it. >I don't suppose there is some way to run the xfs_repair one phase at a time? I am not sure but I think phase 5 involves lot's of seeking which is probably causing this. Making xfs_repair do one phase at a time is not an option. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Oct 26 07:11:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 07:11:13 -0700 (PDT) Received: from mail531.nifty.com (mail531.nifty.com [202.248.37.220]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9QEB8uR006042 for ; Sat, 26 Oct 2002 07:11:08 -0700 Received: from pc3 by mail531.nifty.com (8.12.6/3.7W-07/15/02) with SMTP id g9QE3vxA028621 for ; Sat, 26 Oct 2002 23:03:57 +0900 Date: Sat, 26 Oct 2002 23:03:57 +0900 Message-Id: <200210261403.g9QE3vxA028621@mail531.nifty.com> From: =?ISO-2022-JP?B?GyRCTDVOQSVXJWwlPCVzJUgbKEI=?= To: Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoTDVOQSVXJWwlPCVzJUgbKEI=?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: owner-linux-xfs@oss.sgi.com Precedence: bulk X-list: linux-xfs $B!c;v6HMM$K%W%l%<%s%H$$$?$7$^$9!#1~(B $BJgJ}K!$O$3$A$i$+$i$I$&$>(B http://www.paw.hi-ho.ne.jp/taketu/ From owner-linux-xfs@oss.sgi.com Sat Oct 26 11:47:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 11:47:41 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9QIlZuR022803 for ; Sat, 26 Oct 2002 11:47:36 -0700 Received: from fwd06.sul.t-online.de by mailout03.sul.t-online.com with smtp id 185VyV-0001Re-00; Sat, 26 Oct 2002 20:47:55 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.253.243]) by fmrl06.sul.t-online.com with esmtp id 185VyS-0AMdIOC; Sat, 26 Oct 2002 20:47:52 +0200 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id g9QIlkHF027291; Sat, 26 Oct 2002 20:47:46 +0200 Date: Sat, 26 Oct 2002 20:47:46 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: kernel-2.4.19-SGI_XFS_1.2pre2.src.rpm? Message-ID: <20021026184746.GA26522@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 1300 X-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 new 1.2pre2 contains kernel-...-2.4.19-SGI_XFS_1.2pre2....rpms, where can I find the corresponding src.rpm? ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/SRPMS does not yet contain it. Thanks, Axel. -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Sat Oct 26 12:14:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 12:14:08 -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 g9QJE3uR023409 for ; Sat, 26 Oct 2002 12:14:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA65733; Sat, 26 Oct 2002 14:14:19 -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 OAA47202; Sat, 26 Oct 2002 14:14:19 -0500 (CDT) Date: Sat, 26 Oct 2002 14:09:20 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Axel Thimm cc: linux-xfs@oss.sgi.com Subject: Re: kernel-2.4.19-SGI_XFS_1.2pre2.src.rpm? In-Reply-To: <20021026184746.GA26522@bonzo.nirvana> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1301 X-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 Russell must have forgotten to put it up, and I don't know for sure where he built the RPMs so I'll wait for him to comment. We'll get them up ASAP, though. Thanks, -Eric On Sat, 26 Oct 2002, Axel Thimm wrote: > The new 1.2pre2 contains kernel-...-2.4.19-SGI_XFS_1.2pre2....rpms, where can > I find the corresponding src.rpm? > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/SRPMS does > not yet contain it. > > Thanks, Axel. > -- > Axel.Thimm@physik.fu-berlin.de > > From owner-linux-xfs@oss.sgi.com Sat Oct 26 12:28:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 12:28:23 -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 g9QJSKuR023968 for ; Sat, 26 Oct 2002 12:28:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA46606 for ; Sat, 26 Oct 2002 14:28:37 -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 OAA03847 for ; Sat, 26 Oct 2002 14:28:36 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9QJNbc28411; Sat, 26 Oct 2002 14:23:37 -0500 Message-Id: <200210261923.g9QJNbc28411@stout.americas.sgi.com> Date: Sat, 26 Oct 2002 14:23:37 -0500 Subject: TAKE - Remove tabs from printk's X-archive-position: 1302 X-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 Log parsers don't like them... artifacts of the infamous whitespace cleanup. Remove tabs from printk's Date: Sat Oct 26 12:27:38 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:131185a linux/fs/xfs/xfs_rw.c - 1.369 linux/fs/xfs/xfs_log_recover.c - 1.250 From owner-linux-xfs@oss.sgi.com Sat Oct 26 17:07:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 17:07:39 -0700 (PDT) Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9R07VuR002090 for ; Sat, 26 Oct 2002 17:07:32 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 5349F443C1 for ; Sun, 27 Oct 2002 02:07:53 +0200 (CEST) Received: by chiara.elte.hu (Postfix, from userid 17000) id BD8981FC2; Sun, 27 Oct 2002 02:07:51 +0200 (CEST) Date: Sun, 27 Oct 2002 02:07:51 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: tabs-inside-strings cleanup Message-ID: <20021027000749.GA9138@chiara.elte.hu> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4i Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fuji@elte.hu Precedence: bulk X-list: linux-xfs Eric, As agreed on IRC, here's a preliminary whitespace cleanup patch that takes care of tabs-inside-strings cases. Please review, especially the xfsidbg.c chunk. Patch is against current CVS. (2.4) Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen P閠er / \ / \ / fuji@elte.hu .+' `+...+' `+...+' `+...+' `+...+' Index: xfs_dquot.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_dquot.c,v retrieving revision 1.72 diff -u -u -r1.72 xfs_dquot.c --- xfs_dquot.c 2002/10/23 04:21:07 1.72 +++ xfs_dquot.c 2002/10/27 00:00:33 @@ -1595,31 +1595,31 @@ xfs_qm_dqprint(xfs_dquot_t *dqp) { printk( "-----------KERNEL DQUOT----------------\n"); - printk( "---- dquot ID = %d\n", (int) INT_GET(dqp->q_core.d_id, ARCH_CONVERT)); - printk( "---- type = %s\n", XFS_QM_ISUDQ(dqp) ? "USR" : "GRP"); - printk( "---- fs = 0x%p\n", dqp->q_mount); - printk( "---- blkno = 0x%x\n", (int) dqp->q_blkno); - printk( "---- boffset = 0x%x\n", (int) dqp->q_bufoffset); - printk( "---- blkhlimit = %Lu (0x%x)\n", + printk( "---- dquot ID = %d\n", (int) INT_GET(dqp->q_core.d_id, ARCH_CONVERT)); + printk( "---- type = %s\n", XFS_QM_ISUDQ(dqp) ? "USR" : "GRP"); + printk( "---- fs = 0x%p\n", dqp->q_mount); + printk( "---- blkno = 0x%x\n", (int) dqp->q_blkno); + printk( "---- boffset = 0x%x\n", (int) dqp->q_bufoffset); + printk( "---- blkhlimit = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT), (int) INT_GET(dqp->q_core.d_blk_hardlimit, ARCH_CONVERT)); - printk( "---- blkslimit = %Lu (0x%x)\n", + printk( "---- blkslimit = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT), (int)INT_GET(dqp->q_core.d_blk_softlimit, ARCH_CONVERT)); - printk( "---- inohlimit = %Lu (0x%x)\n", + printk( "---- inohlimit = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_ino_hardlimit, ARCH_CONVERT), (int)INT_GET(dqp->q_core.d_ino_hardlimit, ARCH_CONVERT)); - printk( "---- inoslimit = %Lu (0x%x)\n", + printk( "---- inoslimit = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_ino_softlimit, ARCH_CONVERT), (int)INT_GET(dqp->q_core.d_ino_softlimit, ARCH_CONVERT)); - printk( "---- bcount = %Lu (0x%x)\n", + printk( "---- bcount = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_bcount, ARCH_CONVERT), (int)INT_GET(dqp->q_core.d_bcount, ARCH_CONVERT)); - printk( "---- icount = %Lu (0x%x)\n", + printk( "---- icount = %Lu (0x%x)\n", INT_GET(dqp->q_core.d_icount, ARCH_CONVERT), (int)INT_GET(dqp->q_core.d_icount, ARCH_CONVERT)); - printk( "---- btimer = %d\n", (int)INT_GET(dqp->q_core.d_btimer, ARCH_CONVERT)); - printk( "---- itimer = %d\n", (int)INT_GET(dqp->q_core.d_itimer, ARCH_CONVERT)); + printk( "---- btimer = %d\n", (int)INT_GET(dqp->q_core.d_btimer, ARCH_CONVERT)); + printk( "---- itimer = %d\n", (int)INT_GET(dqp->q_core.d_itimer, ARCH_CONVERT)); printk( "---------------------------\n"); } Index: xfs_ialloc.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c,v retrieving revision 1.161 diff -u -u -r1.161 xfs_ialloc.c --- xfs_ialloc.c 2002/10/23 04:21:07 1.161 +++ xfs_ialloc.c 2002/10/27 00:00:35 @@ -959,7 +959,7 @@ up_read(&mp->m_peraglock); if (error) { cmn_err(CE_WARN, - "xfs_difree: xfs_ialloc_read_agi() returned an error %d on %s. Returning error.", + "xfs_difree: xfs_ialloc_read_agi() returned an error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -995,7 +995,7 @@ */ if ((error = xfs_inobt_lookup_le(cur, agino, 0, 0, &i))) { cmn_err(CE_WARN, - "xfs_difree: xfs_inobt_lookup_le returned() an error %d on %s. Returning error.", + "xfs_difree: xfs_inobt_lookup_le returned() an error %d on %s. Returning error.", error, mp->m_fsname); goto error0; } @@ -1003,7 +1003,7 @@ if ((error = xfs_inobt_get_rec(cur, &rec.ir_startino, &rec.ir_freecount, &rec.ir_free, &i, ARCH_NOCONVERT))) { cmn_err(CE_WARN, - "xfs_difree: xfs_inobt_get_rec() returned an error %d on %s. Returning error.", + "xfs_difree: xfs_inobt_get_rec() returned an error %d on %s. Returning error.", error, mp->m_fsname); goto error0; } @@ -1021,7 +1021,7 @@ rec.ir_freecount++; if ((error = xfs_inobt_update(cur, rec.ir_startino, rec.ir_freecount, rec.ir_free))) { cmn_err(CE_WARN, - "xfs_difree: xfs_inobt_update() returned an error %d on %s. Returning error.", + "xfs_difree: xfs_inobt_update() returned an error %d on %s. Returning error.", error, mp->m_fsname); goto error0; } Index: xfs_inode.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c,v retrieving revision 1.358 diff -u -u -r1.358 xfs_inode.c --- xfs_inode.c 2002/10/23 04:21:07 1.358 +++ xfs_inode.c 2002/10/27 00:00:39 @@ -101,7 +101,7 @@ i * mp->m_sb.sb_inodesize); if (INT_ISZERO(dip->di_next_unlinked, ARCH_CONVERT)) { xfs_fs_cmn_err(CE_ALERT, mp, - "Detected a bogus zero next_unlinked field in incore inode buffer 0x%p. About to pop an ASSERT.", + "Detected a bogus zero next_unlinked field in incore inode buffer 0x%p. About to pop an ASSERT.", bp); ASSERT(!INT_ISZERO(dip->di_next_unlinked, ARCH_CONVERT)); } @@ -190,7 +190,7 @@ error = xfs_imap(mp, tp, ino, &imap, XFS_IMAP_LOOKUP); if (error != 0) { cmn_err(CE_WARN, - "xfs_inotobp: xfs_imap() returned an " + "xfs_inotobp: xfs_imap() returned an " "error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -204,7 +204,7 @@ XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks)) { cmn_err(CE_WARN, "xfs_inotobp: inode number (%d + %d) maps to a block outside the bounds " - "of the file system %s. Returning EINVAL.", + "of the file system %s. Returning EINVAL.", imap.im_blkno, imap.im_len,mp->m_fsname); return XFS_ERROR(EINVAL); } @@ -218,7 +218,7 @@ if (error) { cmn_err(CE_WARN, - "xfs_inotobp: xfs_trans_read_buf() returned an " + "xfs_inotobp: xfs_trans_read_buf() returned an " "error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -230,7 +230,7 @@ XFS_RANDOM_ITOBP_INOTOBP)) { xfs_trans_brelse(tp, bp); cmn_err(CE_WARN, - "xfs_inotobp: XFS_TEST_ERROR() returned an " + "xfs_inotobp: XFS_TEST_ERROR() returned an " "error on %s. Returning EFSCORRUPTED.", mp->m_fsname); return XFS_ERROR(EFSCORRUPTED); } @@ -1908,7 +1908,7 @@ 1, 0, &agibp); if (error != 0) { cmn_err(CE_WARN, - "xfs_iunlink_remove: xfs_trans_read_buf() returned an error %d on %s. Returning error.", + "xfs_iunlink_remove: xfs_trans_read_buf() returned an error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -1923,7 +1923,7 @@ XFS_RANDOM_IUNLINK_REMOVE)) { xfs_trans_brelse(tp, agibp); cmn_err(CE_WARN, - "xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on %s. Returning EFSCORRUPTED.", + "xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on %s. Returning EFSCORRUPTED.", mp->m_fsname); return XFS_ERROR(EFSCORRUPTED); } @@ -1949,7 +1949,7 @@ error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0); if (error) { cmn_err(CE_WARN, - "xfs_iunlink_remove: xfs_itobp() returned an error %d on %s. Returning error.", + "xfs_iunlink_remove: xfs_itobp() returned an error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -1996,7 +1996,7 @@ &last_ibp, &last_offset); if (error) { cmn_err(CE_WARN, - "xfs_iunlink_remove: xfs_inotobp() returned an error %d on %s. Returning error.", + "xfs_iunlink_remove: xfs_inotobp() returned an error %d on %s. Returning error.", error, mp->m_fsname); return error; } @@ -2011,7 +2011,7 @@ error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0); if (error) { cmn_err(CE_WARN, - "xfs_iunlink_remove: xfs_itobp() returned an error %d on %s. Returning error.", + "xfs_iunlink_remove: xfs_itobp() returned an error %d on %s. Returning error.", error, mp->m_fsname); return error; } Index: xfs_log_recover.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c,v retrieving revision 1.249 diff -u -u -r1.249 xfs_log_recover.c --- xfs_log_recover.c 2002/10/23 04:21:07 1.249 +++ xfs_log_recover.c 2002/10/27 00:00:46 @@ -142,10 +142,10 @@ { int b; - printk("xlog_header_check_dump:\n SB : uuid = "); + printk("xlog_header_check_dump:\n SB : uuid = "); for (b=0;b<16;b++) printk("%02x",((unsigned char *)&mp->m_sb.sb_uuid)[b]); printk(", fmt = %d\n",XLOG_FMT); - printk(" log: uuid = "); + printk(" log: uuid = "); for (b=0;b<16;b++) printk("%02x",((unsigned char *)&head->h_fs_uuid)[b]); printk(", fmt = %d\n", INT_GET(head->h_fmt, ARCH_CONVERT)); } Index: xfs_mount.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c,v retrieving revision 1.308 diff -u -u -r1.308 xfs_mount.c --- xfs_mount.c 2002/10/23 04:21:07 1.308 +++ xfs_mount.c 2002/10/27 00:00:49 @@ -1200,7 +1200,7 @@ xfs_ioerror_alert("xfs_unmountfs_writesb", mp, sbp, XFS_BUF_ADDR(sbp)); if (error && mp->m_mk_sharedro) - xfs_fs_cmn_err(CE_ALERT, mp, "Superblock write error detected while unmounting. Filesystem may not be marked shared readonly"); + xfs_fs_cmn_err(CE_ALERT, mp, "Superblock write error detected while unmounting. Filesystem may not be marked shared readonly"); } xfs_buf_relse(sbp); return (error); Index: xfs_qm_syscalls.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_qm_syscalls.c,v retrieving revision 1.71 diff -u -u -r1.71 xfs_qm_syscalls.c --- xfs_qm_syscalls.c 2002/10/23 04:21:07 1.71 +++ xfs_qm_syscalls.c 2002/10/27 00:01:08 @@ -1173,11 +1173,11 @@ xfs_dqtest_t *d) { printk("-----------DQTEST DQUOT----------------\n"); - printk("---- dquot ID = %d\n", d->d_id); - printk("---- type = %s\n", XFS_QM_ISUDQ(d) ? "USR" : "GRP"); - printk("---- fs = 0x%p\n", d->q_mount); - printk("---- bcount = %Lu (0x%x)\n", d->d_bcount, (int)d->d_bcount); - printk("---- icount = %Lu (0x%x)\n", d->d_icount, (int)d->d_icount); + printk("---- dquot ID = %d\n", d->d_id); + printk("---- type = %s\n", XFS_QM_ISUDQ(d) ? "USR" : "GRP"); + printk("---- fs = 0x%p\n", d->q_mount); + printk("---- bcount = %Lu (0x%x)\n", d->d_bcount, (int)d->d_bcount); + printk("---- icount = %Lu (0x%x)\n", d->d_icount, (int)d->d_icount); printk("---------------------------\n"); } @@ -1451,10 +1451,10 @@ } if (qmtest_nfails) { - printk("************** quotacheck failed **************\n"); + printk("************** quotacheck failed **************\n"); printk("failures = %d\n", qmtest_nfails); } else { - printk("************** quotacheck successful! **************\n"); + printk("************** quotacheck successful! **************\n"); } kmem_free(qmtest_udqtab, qmtest_hashmask * sizeof(xfs_dqhash_t)); kmem_free(qmtest_gdqtab, qmtest_hashmask * sizeof(xfs_dqhash_t)); Index: xfs_rw.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c,v retrieving revision 1.368 diff -u -u -r1.368 xfs_rw.c --- xfs_rw.c 2002/10/24 20:18:15 1.368 +++ xfs_rw.c 2002/10/27 00:01:08 @@ -231,7 +231,7 @@ { cmn_err(CE_ALERT, "I/O error in filesystem (\"%s\") meta-data dev 0x%x block 0x%llx" - " (\"%s\") error %d buf count %u", + " (\"%s\") error %d buf count %u", (!mp || !mp->m_fsname) ? "(fs name not set)" : mp->m_fsname, XFS_BUF_TARGET_DEV(bp), (__uint64_t)blkno, Index: xfs_vnodeops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c,v retrieving revision 1.570 diff -u -u -r1.570 xfs_vnodeops.c --- xfs_vnodeops.c 2002/10/23 04:21:07 1.570 +++ xfs_vnodeops.c 2002/10/27 00:01:10 @@ -1840,7 +1840,7 @@ */ if (!XFS_FORCED_SHUTDOWN(tp->t_mountp)) { cmn_err(CE_NOTE, - "xfs_inactive: xfs_ifree() returned an error = %d on %s", + "xfs_inactive: xfs_ifree() returned an error = %d on %s", error,tp->t_mountp->m_fsname); xfs_force_shutdown(tp->t_mountp, XFS_METADATA_IO_ERROR); } Index: xfsidbg.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c,v retrieving revision 1.208 diff -u -u -r1.208 xfsidbg.c --- xfsidbg.c 2002/10/21 05:23:40 1.208 +++ xfsidbg.c 2002/10/27 00:01:14 @@ -1642,7 +1642,7 @@ kdev_t_to_nr(ip->i_dev), ip->i_size); kdb_printf( - " i_mode = 0x%x i_nlink = %d i_rdev = 0x%x i_state = 0x%lx\n", + " i_mode = 0x%x i_nlink = %d i_rdev = 0x%x i_state = 0x%lx\n", ip->i_mode, ip->i_nlink, kdev_t_to_nr(ip->i_rdev), ip->i_state); @@ -1753,7 +1753,7 @@ for (index = 0; flags && mapping[index]; flags >>= 1, index++) { if (flags & 1) { if ((offset + strlen(mapping[index]) + 1) >= 80) { - strcat(buffer, "\n "); + strcat(buffer, "\n "); offset = 12; } else if (offset > 12) { strcat(buffer, " "); @@ -2009,9 +2009,9 @@ trace->misc); kdb_symbol_print((unsigned int)trace->ra, NULL, KDB_SP_SPACEB|KDB_SP_PAREN|KDB_SP_NEWLINE); - kdb_printf(" offset 0x%Lx size 0x%x task 0x%p\n", + kdb_printf(" offset 0x%Lx size 0x%x task 0x%p\n", trace->offset, trace->size, trace->task); - kdb_printf(" flags: %s\n", + kdb_printf(" flags: %s\n", pb_flags(trace->flags)); } } @@ -2612,7 +2612,7 @@ kdb_printf("buf 0x%p blkno 0x%Lx ", blip->bli_buf, blip->bli_format.blf_blkno); printflags(blip->bli_flags, bli_flags, "flags:"); - kdb_printf("\n "); + kdb_printf("\n "); xfsidbg_xbuf_real(blip->bli_buf, 1); return; } @@ -2681,7 +2681,7 @@ kdb_printf("efd extents:\n"); ep = &(efdp->efd_format.efd_extents[0]); for (i = 0; i < efdp->efd_next_extent; i++, ep++) { - kdb_printf(" block %Lx len %d\n", + kdb_printf(" block %Lx len %d\n", ep->ext_start, ep->ext_len); } } @@ -2716,7 +2716,7 @@ kdb_printf("efi extents:\n"); ep = &(efip->efi_format.efi_extents[0]); for (i = 0; i < efip->efi_next_extent; i++, ep++) { - kdb_printf(" block %Lx len %d\n", + kdb_printf(" block %Lx len %d\n", ep->ext_start, ep->ext_len); } } @@ -3267,7 +3267,7 @@ k = ~(XFS_ATTR_LOCAL | XFS_ATTR_ROOT | XFS_ATTR_INCOMPLETE); if ((e->flags & k) != 0) kdb_printf("0x%x", e->flags & k); - kdb_printf(">\n name \""); + kdb_printf(">\n name \""); if (e->flags & XFS_ATTR_LOCAL) { l = XFS_ATTR_LEAF_NAME_LOCAL(leaf, j); for (k = 0; k < l->namelen; k++) @@ -4023,7 +4023,7 @@ kdb_printf("xlog_in_core/header at 0x%p/0x%p\n", iclog, iclog->hic_data); - kdb_printf("magicno: %x cycle: %d version: %d lsn: 0x%Lx\n", + kdb_printf("magicno: %x cycle: %d version: %d lsn: 0x%Lx\n", INT_GET(iclog->ic_header.h_magicno, ARCH_CONVERT), INT_GET(iclog->ic_header.h_cycle, ARCH_CONVERT), INT_GET(iclog->ic_header.h_version, ARCH_CONVERT), INT_GET(iclog->ic_header.h_lsn, ARCH_CONVERT)); kdb_printf("tail_lsn: 0x%Lx len: %d prev_block: %d num_ops: %d\n", @@ -4031,13 +4031,13 @@ INT_GET(iclog->ic_header.h_prev_block, ARCH_CONVERT), INT_GET(iclog->ic_header.h_num_logops, ARCH_CONVERT)); kdb_printf("cycle_data: "); for (i=0; i<(iclog->ic_size>>BBSHIFT); i++) { - kdb_printf("%x ", INT_GET(iclog->ic_header.h_cycle_data[i], ARCH_CONVERT)); + kdb_printf("%x ", INT_GET(iclog->ic_header.h_cycle_data[i], ARCH_CONVERT)); } kdb_printf("\n"); kdb_printf("size: %d\n", INT_GET(iclog->ic_header.h_size, ARCH_CONVERT)); kdb_printf("\n"); kdb_printf("--------------------------------------------------\n"); - kdb_printf("data: 0x%p &forcesema: 0x%p next: 0x%p bp: 0x%p\n", + kdb_printf("data: 0x%p &forcesema: 0x%p next: 0x%p bp: 0x%p\n", iclog->ic_datap, &iclog->ic_forcesema, iclog->ic_next, iclog->ic_bp); kdb_printf("log: 0x%p callb: 0x%p callb_tail: 0x%p roundoff: %d\n", @@ -4207,14 +4207,14 @@ }; kdb_printf("xlog at 0x%p\n", log); - kdb_printf("&flushsm: 0x%p tic_cnt: %d tic_tcnt: %d \n", + kdb_printf("&flushsm: 0x%p tic_cnt: %d tic_tcnt: %d \n", &log->l_flushsema, log->l_ticket_cnt, log->l_ticket_tcnt); - kdb_printf("freelist: 0x%p tail: 0x%p ICLOG: 0x%p \n", + kdb_printf("freelist: 0x%p tail: 0x%p ICLOG: 0x%p \n", log->l_freelist, log->l_tail, log->l_iclog); kdb_printf("&icloglock: 0x%p tail_lsn: %s last_sync_lsn: %s \n", &log->l_icloglock, xfs_fmtlsn(&log->l_tail_lsn), xfs_fmtlsn(&log->l_last_sync_lsn)); - kdb_printf("mp: 0x%p xbuf: 0x%p roundoff: %d l_covered_state: %s \n", + kdb_printf("mp: 0x%p xbuf: 0x%p roundoff: %d l_covered_state: %s \n", log->l_mp, log->l_xbuf, log->l_roundoff, xfsidbg_get_cstate(log->l_covered_state)); kdb_printf("flags: "); @@ -4232,7 +4232,7 @@ log->l_iclog_hsize, log->l_iclog_heads); kdb_printf("&grant_lock: 0x%p resHeadQ: 0x%p wrHeadQ: 0x%p\n", &log->l_grant_lock, log->l_reserve_headq, log->l_write_headq); - kdb_printf("GResCycle: %d GResBytes: %d GWrCycle: %d GWrBytes: %d\n", + kdb_printf("GResCycle: %d GResBytes: %d GWrCycle: %d GWrBytes: %d\n", log->l_grant_reserve_cycle, log->l_grant_reserve_bytes, log->l_grant_write_cycle, log->l_grant_write_bytes); rbytes = log->l_grant_reserve_bytes + log->l_roundoff; @@ -4394,9 +4394,9 @@ }; kdb_printf("xlog_ticket at 0x%p\n", tic); - kdb_printf("next: 0x%p prev: 0x%p tid: 0x%x \n", + kdb_printf("next: 0x%p prev: 0x%p tid: 0x%x \n", tic->t_next, tic->t_prev, tic->t_tid); - kdb_printf("curr_res: %d unit_res: %d ocnt: %d cnt: %d\n", + kdb_printf("curr_res: %d unit_res: %d ocnt: %d cnt: %d\n", tic->t_curr_res, tic->t_unit_res, (int)tic->t_ocnt, (int)tic->t_cnt); kdb_printf("clientid: %c \n", tic->t_clientid); @@ -4514,7 +4514,7 @@ kdb_printf("[%d] type %s ", count, lid_type[lip->li_type - XFS_LI_5_3_BUF + 1]); printflags((uint)(lip->li_flags), li_flags, "flags:"); - kdb_printf(" lsn %s\n ", xfs_fmtlsn(&(lip->li_lsn))); + kdb_printf(" lsn %s\n ", xfs_fmtlsn(&(lip->li_lsn))); switch (lip->li_type) { case XFS_LI_BUF: xfs_buf_item_print((xfs_buf_log_item_t *)lip, 1); @@ -4890,13 +4890,13 @@ pag->pagf_flcount, pag->pagf_freeblks, pag->pagf_longest, pag->pagf_metadata); if (pag->pagi_init) - kdb_printf(" i_freecount %d i_inodeok %d\n", + kdb_printf(" i_freecount %d i_inodeok %d\n", pag->pagi_freecount, pag->pagi_inodeok); if (pag->pagf_init) { for (busy = 0; busy < XFS_PAGB_NUM_SLOTS; busy++) { if (pag->pagb_list[busy].busy_length != 0) { kdb_printf( - " %04d: start %d length %d tp 0x%p\n", + " %04d: start %d length %d tp 0x%p\n", busy, pag->pagb_list[busy].busy_start, pag->pagb_list[busy].busy_length, @@ -4980,7 +4980,7 @@ printflags(dqp->dq_flags, qflags, "flags:"); kdb_printf("\nblkno 0x%llx\tboffset 0x%x\n", (unsigned long long) dqp->q_blkno, (int) dqp->q_bufoffset); - kdb_printf("qlock 0x%p flock 0x%p (%s) pincount 0x%x\n", + kdb_printf("qlock 0x%p flock 0x%p (%s) pincount 0x%x\n", &dqp->q_qlock, &dqp->q_flock, (valusema(&dqp->q_flock) <= 0) ? "LCK" : "UNLKD", From owner-linux-xfs@oss.sgi.com Sat Oct 26 17:13:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 17:13:53 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0DnuR002630 for ; Sat, 26 Oct 2002 17:13:49 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R0DmJ9002627 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 17:13:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0Djuh002563 for ; Sat, 26 Oct 2002 17:13:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R08wsE002255; Sat, 26 Oct 2002 17:08:58 -0700 Date: Sat, 26 Oct 2002 17:08:58 -0700 Message-Id: <200210270008.g9R08wsE002255@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-26 17:08 ------- Created an attachment (id=43) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=43&action=view) wrapper around dostress which creates clean filesystems, etc This script was originally used when I was testing with mixed local and NFS accesses; it now contains the framework to make a clean filesystem and start the test. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 17:13:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 17:13:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0DnuR002632 for ; Sat, 26 Oct 2002 17:13:49 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R0DmHB002628 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 17:13:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0Djuf002563 for ; Sat, 26 Oct 2002 17:13:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R07LMM002081; Sat, 26 Oct 2002 17:07:21 -0700 Date: Sat, 26 Oct 2002 17:07:21 -0700 Message-Id: <200210270007.g9R07LMM002081@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-26 17:07 ------- Created an attachment (id=42) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=42&action=view) fsstress script Contains a seed for fsstress that seems to trigger this bug reliably when used across NFS ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 17:13:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 17:13:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0DnuR002638 for ; Sat, 26 Oct 2002 17:13:49 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R0DnR3002635 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 17:13:49 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0Djur002563 for ; Sat, 26 Oct 2002 17:13:47 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R01qUj001949; Sat, 26 Oct 2002 17:01:52 -0700 Date: Sat, 26 Oct 2002 17:01:52 -0700 Message-Id: <200210270001.g9R01qUj001949@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 188] New: xfsdump dumps unnecessary files/inodes when doing incremental dumps X-Bugzilla-Reason: AssignedTo X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=188 Summary: xfsdump dumps unnecessary files/inodes when doing incremental dumps Product: Linux XFS Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Medium Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: cw@f00f.org xfsprogs (all versions from when Noah was a boy to present) dump unnecessary files/inodes when doing incremental dumps. When files are moved/renamed (causing a directory to be changed), all files in the directory (or directories in the example below) are dumped again --- even when they are older than the dump's time stamp. For example, if you were to dump (level 0) the following: dir1/file1 dir1/file2 dir1/file3 and then after the level 0 dump do: mkdir dir2 mv dir1/file2 dir1/file1 or whatever... xfsdump will dump not only dir1 and dir2, but also all the files contained within (ie. dir1/file1, dir2/file2, dir1/file3). This is unnecessary as the file contents and inodes have not changed, and extremely annoying when a file in (say) /usr/bin gets renamed or whatever as the entire directory gets dumped. Obviously, renames of multiGB files really hurt. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 17:13:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 17:13:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0DnuR002631 for ; Sat, 26 Oct 2002 17:13:49 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R0DnL7002629 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 17:13:49 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R0Djud002563 for ; Sat, 26 Oct 2002 17:13:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R04tSq001997; Sat, 26 Oct 2002 17:04:55 -0700 Date: Sat, 26 Oct 2002 17:04:55 -0700 Message-Id: <200210270004.g9R04tSq001997@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-26 17:04 ------- Eric, I'd hazard a guess that Juri's problem is the same as the one that Christian and I are seeing in this bug. I also believe it is the same as Tim is experiencing in bug 187. It looks as though the common factor is we all have a XFS filesystem exported via NFS. I've checked with Tim and he is exporting a filesystem via NFS on the system he reported the problems for. Regarding it not being reproducable - you're in luck. I can reproduce this problem, usually within 30 minutes or so, by running fsstress on an XFS filesystem exported via NFS - across the NFS mount. I always get a xfs_force_shutdown generated in xfs_trans.c (which corresponds with a dirty transaction being aborted). I will upload the scripts that I use for my tests briefly - they're nothing fancy, but do contain a random number seed that seems to cause everything to reliably fail for me. Things I've eliminated: * LVM - I get the errors using a plain block device; * compiler version - I have built with kgcc (egcs 2.91.66) and RedHat gcc 2.96-98; both report the error * SMP - a CONFIG_SMP=n build still fails * HIGHMEM - Tim's system is SMP with 512MB RAM, and fails * NFS v3/v2 - I have mounted the filesystem with both versions 2 and 3; I receive the error with both. The XFS version I am testing now is: SGI XFS CVS-10/26/02:05 with ACLs, quota, no debug enabled however, the problem existed at 3/10/2002. I plan to step back through time and see if I can track down when the problem developed. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:09:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:09:07 -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 g9R292uR005154 for ; Sat, 26 Oct 2002 19:09:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA33030; Sat, 26 Oct 2002 21:09:19 -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 VAA71189; Sat, 26 Oct 2002 21:09:18 -0500 (CDT) Date: Sat, 26 Oct 2002 21:04:16 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: KELEMEN Peter cc: linux-xfs@oss.sgi.com Subject: Re: tabs-inside-strings cleanup In-Reply-To: <20021027000749.GA9138@chiara.elte.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ledzep.americas.sgi.com id VAA33030 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9R293uR005155 X-archive-position: 1308 X-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 Thanks Peter, can you send me the regexp-y things you used to check for these, I'll look and see how many of them were originally intended to be tabs. -Eric On Sun, 27 Oct 2002, KELEMEN Peter wrote: > Eric, > > As agreed on IRC, here's a preliminary whitespace cleanup patch > that takes care of tabs-inside-strings cases. Please review, > especially the xfsidbg.c chunk. Patch is against current CVS. > (2.4) > > Peter > > -- > .+'''+. .+'''+. .+'''+. .+'''+. .+'' > Kelemen P閠er / \ / \ / fuji@elte.hu > .+' `+...+' `+...+' `+...+' `+...+' > From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:13:48 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2DkuR005639 for ; Sat, 26 Oct 2002 19:13:46 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2DkGK005638 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 19:13:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2DjuV005620 for ; Sat, 26 Oct 2002 19:13:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2Dapw005614; Sat, 26 Oct 2002 19:13:36 -0700 Date: Sat, 26 Oct 2002 19:13:36 -0700 Message-Id: <200210270213.g9R2Dapw005614@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-10-26 19:13 ------- Thanks for all the extra info on this, and the work you've done, Chris! Also, Juri - sorry, yours -was- the same problem, I had my bug wires crossed. Any of you guys who can hit this regularly, willing to turn on a couple ASSERTS? -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:29:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:29:12 -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 g9R2T9uR006131 for ; Sat, 26 Oct 2002 19:29:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA85508 for ; Sat, 26 Oct 2002 21:29: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 VAA53307 for ; Sat, 26 Oct 2002 21:29:25 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9R2ONg29288; Sat, 26 Oct 2002 21:24:23 -0500 Message-Id: <200210270224.g9R2ONg29288@stout.americas.sgi.com> Date: Sat, 26 Oct 2002 21:24:23 -0500 Subject: TAKE - fix forced shutdown on LVM snapshots X-archive-position: 1310 X-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 Erik was seeing this because he had a couple files in an odd state (probably due to a crash) with speculatively-allocated blocks remaining past EOF. When he tried to tar up the read-only snapshot, and read each file, xfs tried to clean up these past-EOF-blocks when the file was closed. This generated I/O on a read-only device, which failed, and shut down the fs. See below for how this mod works around this problem. Prevent a couple transactions from happening on ro mounts Date: Sat Oct 26 19:27:15 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:131187a linux/fs/xfs/xfs_log.c - 1.260 - Temporarily turn off VFS_RDONLY flag for read-only mounts, during recovery. (Recovery still won't proceed, however, on a read-only device). linux/fs/xfs/xfs_vnodeops.c - 1.571 - Before calling xfs_inactive_free_eofblocks, check for VFS_RDONLY. Don't do it if it's set, as this may be a read-only device, and the resulting log I/O would shut down the fs. If this is just a read-only mount & we're recovering the log, VFS_RDONLY will be turned off and we'll proceed. From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:43:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:43:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hmuR006682 for ; Sat, 26 Oct 2002 19:43:48 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2hmXo006679 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 19:43:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hjuf006632 for ; Sat, 26 Oct 2002 19:43:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2Uan6006532; Sat, 26 Oct 2002 19:30:36 -0700 Date: Sat, 26 Oct 2002 19:30:36 -0700 Message-Id: <200210270230.g9R2Uan6006532@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 184] xfs_force_shutdown called on lvm-snapshot X-Bugzilla-Reason: AssignedTo X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=184 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From sandeen@sgi.com 2002-10-26 19:30 ------- Should be fixed with mod 2.4.x-xfs:slinx:131187a ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:43:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:43:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hmuR006681 for ; Sat, 26 Oct 2002 19:43:48 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2hmK6006680 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 19:43:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hjuV006632 for ; Sat, 26 Oct 2002 19:43:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2EKiw005899; Sat, 26 Oct 2002 19:14:20 -0700 Date: Sat, 26 Oct 2002 19:14:20 -0700 Message-Id: <200210270214.g9R2EKiw005899@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 187] XFS memory corruption X-Bugzilla-Reason: AssignedTo X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=187 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From sandeen@sgi.com 2002-10-26 19:14 ------- *** This bug has been marked as a duplicate of 186 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 19:43:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 19:43:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hmuR006683 for ; Sat, 26 Oct 2002 19:43:48 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2hmOt006678 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 19:43:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R2hjub006632 for ; Sat, 26 Oct 2002 19:43:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R2EL0A005909; Sat, 26 Oct 2002 19:14:21 -0700 Date: Sat, 26 Oct 2002 19:14:21 -0700 Message-Id: <200210270214.g9R2EL0A005909@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |waitt@saic.com ------- Additional Comments From sandeen@sgi.com 2002-10-26 19:14 ------- *** Bug 187 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 20:43:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 20:43:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R3hkuR008856 for ; Sat, 26 Oct 2002 20:43:46 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R3hkJB008855 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 20:43:46 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R3hjuX008835 for ; Sat, 26 Oct 2002 20:43:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R3LoQm008699; Sat, 26 Oct 2002 20:21:50 -0700 Date: Sat, 26 Oct 2002 20:21:50 -0700 Message-Id: <200210270321.g9R3LoQm008699@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-26 20:21 ------- Happy to turn on whatever you think will be useful. I have done a debug build and set panic_mask to 127; no asserts tripped, but it did panic as promised. xfs_force_shutdown(lvm(58,0),0x8) called from line 1055 of file xfs_trans.c. Return address = 0xf8a5603f (this line number doesn't match, I was trying changed code) Filesystem "lvm(58,0)": xfs_itobp: xfs_trans_read_buf() returned error 5, imap.im_blkno 0x27a00, imap.im_len 0x10 XFS: Transforming an alert into a BUG. Filesystem "lvm(58,0)": Corruption of in-memory data detected. Shutting down filesystem: lvm(58,0) The one time I ran this, it was a mkdir operation being cancelled. In case it's of any use, I've disabled linvfs_fh_to_dentry/linvfs_dentry_to_fh operations (and reinstated xfs_read_inode) on my kernel and retested. I don't get the shutdown now - but after a few hours of running I got a NULL pointer dereference in nfsd_findparent, on the line: pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry); I've added checks to find out exactly which pointer was NULL, and am trying again.. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 26 22:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Oct 2002 22:13:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R5DluR010569 for ; Sat, 26 Oct 2002 22:13:47 -0700 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R5DlCf010568 for linux-xfs@oss.sgi.com; Sat, 26 Oct 2002 22:13:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9R5DjuX010548 for ; Sat, 26 Oct 2002 22:13:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9R4od0x009835; Sat, 26 Oct 2002 21:50:39 -0700 Date: Sat, 26 Oct 2002 21:50:39 -0700 Message-Id: <200210270450.g9R4od0x009835@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown on a lvm device X-Bugzilla-Reason: AssignedTo X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-26 21:50 ------- I'm afraid that I can't go back in time using the CVS tree to search down when this started - unless someone can tell me how to get back files that have been deleted along the way (e.g., how do I retrieve rev 1.13 of fs/xfs/linux/xfs_xattr.c?) Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Oct 27 00:13:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 00:13:36 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9R7DUuR012357 for ; Sun, 27 Oct 2002 00:13:31 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g9R7Drl23833 for ; Sun, 27 Oct 2002 16:13:53 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g9R7DrJ05170 for ; Sun, 27 Oct 2002 16:13:53 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g9R7Dq208376 for ; Sun, 27 Oct 2002 16:13:52 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA448 for ; Sun, 27 Oct 2002 16:13:50 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Sun Oct 27 16:13:49 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g9R7Dpb08486 for ; Sun, 27 Oct 2002 16:13:51 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g9R7DpI10709 for ; Sun, 27 Oct 2002 16:13:51 +0900 To: linux-xfs@oss.sgi.com Subject: fix 2.4-xfs pagebuf request X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Informed Management) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021027161351Z.masano@tnes.nec.co.jp> Date: Sun, 27 Oct 2002 16:13:51 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 30 X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Hi, I found a bug at current 2.4 CVS about `struct pagesync_t'. Some driver top-half may call buffer_head.b_end_io() on process context (not interrupt context). So _end_pagebuf_page_io_multi() may be called several times with remain==1. Please fix it. Here is a patch. -- Masano --- linux/fs/xfs/pagebuf/page_buf.c Fri Oct 25 07:46:20 2002 +++ linux/fs/xfs/pagebuf/page_buf.c.new Sun Oct 27 15:53:38 2002 @@ -1645,7 +1645,7 @@ BUG(); /* Ugh - out of memory condition here */ psync->pb = pb; psync->locking = locking; - atomic_set(&psync->remain, 0); + atomic_set(&psync->remain, cnt); callback = public_bh ? _end_io_multi_part : _end_io_multi_full; @@ -1667,7 +1667,6 @@ /* Complete the buffer_head, then submit the IO */ if (psync) { init_buffer(bh, callback, psync); - atomic_inc(&psync->remain); } else { init_buffer(bh, callback, pb); } From owner-linux-xfs@oss.sgi.com Sun Oct 27 05:06:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 05:06:45 -0800 (PST) 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 g9RD6duR025410 for ; Sun, 27 Oct 2002 05:06:39 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA48843; Sun, 27 Oct 2002 07:06:57 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-21.corp.sgi.com [134.15.64.21]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA38280; Sun, 27 Oct 2002 07:06:53 -0600 (CST) Subject: Re: fix 2.4-xfs pagebuf request From: Stephen Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021027161351Z.masano@tnes.nec.co.jp> References: <20021027161351Z.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 27 Oct 2002 07:02:29 -0600 Message-Id: <1035723752.1058.13.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2002-10-27 at 01:13, ASANO Masahiro wrote: > Hi, > > I found a bug at current 2.4 CVS about `struct pagesync_t'. > Some driver top-half may call buffer_head.b_end_io() on process > context (not interrupt context). So _end_pagebuf_page_io_multi() may > be called several times with remain==1. Ah, I see the problem, we may get I/O completion callbacks before we have submitted all the parts of the I/O. Which does indeed mean we can get I/O completion calls more than expected. Thank you. Steve From owner-linux-xfs@oss.sgi.com Sun Oct 27 07:35:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 07:35:05 -0800 (PST) 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 g9RFYwuR028785 for ; Sun, 27 Oct 2002 07:34:59 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 185pRg-0005UI-00; Sun, 27 Oct 2002 15:35:20 +0000 Date: Sun, 27 Oct 2002 15:35:20 +0000 From: Christoph Hellwig To: ASANO Masahiro , Luben Tuikov Cc: linux-xfs@oss.sgi.com Subject: Re: fix 2.4-xfs pagebuf request Message-ID: <20021027153520.A21019@infradead.org> References: <20021027161351Z.masano@tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021027161351Z.masano@tnes.nec.co.jp>; from masano@tnes.nec.co.jp on Sun, Oct 27, 2002 at 04:13:51PM +0900 X-archive-position: 1318 X-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 Sun, Oct 27, 2002 at 04:13:51PM +0900, ASANO Masahiro wrote: > Hi, > > I found a bug at current 2.4 CVS about `struct pagesync_t'. > Some driver top-half may call buffer_head.b_end_io() on process > context (not interrupt context). So _end_pagebuf_page_io_multi() may > be called several times with remain==1. Thanks for the patch. Luben, I think this patch will fix your lvm+raid setup, could you try it? > --- linux/fs/xfs/pagebuf/page_buf.c Fri Oct 25 07:46:20 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c.new Sun Oct 27 15:53:38 2002 > @@ -1645,7 +1645,7 @@ > BUG(); /* Ugh - out of memory condition here */ > psync->pb = pb; > psync->locking = locking; > - atomic_set(&psync->remain, 0); > + atomic_set(&psync->remain, cnt); > > callback = public_bh ? > _end_io_multi_part : _end_io_multi_full; > @@ -1667,7 +1667,6 @@ > /* Complete the buffer_head, then submit the IO */ > if (psync) { > init_buffer(bh, callback, psync); > - atomic_inc(&psync->remain); > } else { > init_buffer(bh, callback, pb); > } > > From owner-linux-xfs@oss.sgi.com Sun Oct 27 11:43:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 11:43:48 -0800 (PST) Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9RJhfuR030601 for ; Sun, 27 Oct 2002 11:43:44 -0800 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id B72664428A for ; Sun, 27 Oct 2002 20:44:05 +0100 (CET) Received: by chiara.elte.hu (Postfix, from userid 17000) id 789161FC2; Sun, 27 Oct 2002 20:44:04 +0100 (CET) Date: Sun, 27 Oct 2002 20:44:03 +0100 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: tabs-inside-strings cleanup Message-ID: <20021027194402.GA25985@chiara.elte.hu> Reply-To: KELEMEN Peter Mail-Followup-To: linux-xfs@oss.sgi.com References: <20021027000749.GA9138@chiara.elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fuji@elte.hu Precedence: bulk X-list: linux-xfs * Eric Sandeen (sandeen@sgi.com) [20021026 21:04]: > Thanks Peter, can you send me the regexp-y things you used > to check for these, I'll look and see how many of them were > originally intended to be tabs. Well, since all the irrelevant matches of a primitive grep '".*^I\+.*"' # literal Tab there... were in xfsidbg.c, I just went over them inside vim and made changes according to "sanity" as we all know it. :-) There was no need to write a parser, hope I didn't miss something important. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen P閠er / \ / \ / fuji@elte.hu .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Sun Oct 27 13:45:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 13:45:39 -0800 (PST) Received: from morpheus.matrix.com (193-153-180-162.uc.nombres.ttd.es [193.153.180.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9RLjSuR031627 for ; Sun, 27 Oct 2002 13:45:30 -0800 Received: (qmail 5606 invoked by uid 1000); 27 Oct 2002 21:47:06 -0000 From: yoros@wanadoo.es Date: Sun, 27 Oct 2002 22:47:06 +0100 To: linux-xfs Subject: Little questions Message-ID: <20021027214706.GA5589@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have a few questions about XFS and generic filesystem management. The first question is about the creation of sparse files. I want to learn more and more. Another question is related to the process of deleting files. How does XFS delete a file?. Does XFS have a list of extents? (because it is slow when deleting a file that has lots of extents). Thank you for your time, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9vF7aWIvihXTx06wRAm3GAJsFP/ZHWIABzr0VBey/mbDUaq/ygQCgkag6 vXIMrh76SH04y9ju8sFK5GA= =Duvu -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-linux-xfs@oss.sgi.com Sun Oct 27 17:45:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 17:46:02 -0800 (PST) Received: from angband.namesys.com (angband.namesys.com [212.16.7.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9S1jsuR000950 for ; Sun, 27 Oct 2002 17:45:55 -0800 Received: by angband.namesys.com (Postfix on SuSE Linux 7.3 (i386), from userid 521) id 8BF3E2AE46C; Fri, 25 Oct 2002 09:48:04 +0400 (MSD) Date: Fri, 25 Oct 2002 09:48:04 +0400 From: Oleg Drokin To: Fabien Combernous Cc: ext3-users@redhat.com, jfs-discussion , reiserfs , linux-xfs@oss.sgi.com Subject: Re: [reiserfs-list] To compare Linux journalised filesystem, part II. Message-ID: <20021025094804.A1197@namesys.com> References: <3DB823AA.6010405@eprocess.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3DB823AA.6010405@eprocess.fr> User-Agent: Mutt/1.3.22.1i X-archive-position: 1321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: green@namesys.com Precedence: bulk X-list: linux-xfs Hello! On Thu, Oct 24, 2002 at 06:45:30PM +0200, Fabien Combernous wrote: > +------------------+-----+------+-----+----------+------------------------------------------------------------------------+ > | NFS | Y | Y | Y | Y | nfs works on all of them. You need at least reiserfs v3.6. NFS will work with reiserfs v3.5 too, just there is a probability of having problems with reusing object ids (and therefore the inode numbers too). > |data journal | N | Y | N | N | Only ext3 can take care of data by a data journal. All other journaled | > | | | | | | file systems have "only" a metadata journal. | No. Chris Mason have set of patches that implement data journaling for reiserfs, too. Bye, Oleg From owner-linux-xfs@oss.sgi.com Sun Oct 27 18:46:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 18:46:54 -0800 (PST) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9S2knuR002016 for ; Sun, 27 Oct 2002 18:46:50 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g9S2lFl09636 for ; Mon, 28 Oct 2002 11:47:15 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g9S2lE827037 for ; Mon, 28 Oct 2002 11:47:14 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g9S2lD215757 for ; Mon, 28 Oct 2002 11:47:13 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA471 for ; Mon, 28 Oct 2002 11:47:08 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Oct 28 11:47:05 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g9S2l9b25731 for ; Mon, 28 Oct 2002 11:47:09 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g9S2l9I28080 for ; Mon, 28 Oct 2002 11:47:09 +0900 To: linux-xfs@oss.sgi.com Subject: xfs_syncsub() question X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Informed Management) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021028114709M.masano@tnes.nec.co.jp> Date: Mon, 28 Oct 2002 11:47:09 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 20 X-archive-position: 1322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Hi, I have a question. Why don't we sync the last xfs_inode in xfs_syncsub()? I am wondering if the condition check is wrong... (see below) -- Masano --- linux/fs/xfs/xfs_vfsops.c Thu Oct 24 07:46:17 2002 +++ linux/fs/xfs/xfs_vfsops.c.new Mon Oct 28 11:29:21 2002 @@ -1433,7 +1433,7 @@ ASSERT(ipointer_in == B_FALSE); ip = ip->i_mnext; - } while (ip->i_mnext != mp->m_inodes); + } while (ip != mp->m_inodes); XFS_MOUNT_IUNLOCK(mp); From owner-linux-xfs@oss.sgi.com Sun Oct 27 18:56:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 18:56:03 -0800 (PST) Received: from ns.ad-hoc.org (IDENT:postfix@n226.brail.gakushuin.ac.jp [150.90.47.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9S2txuR002487 for ; Sun, 27 Oct 2002 18:56:00 -0800 Received: from localhost.localdomain.ad-hoc.org (ns.ad-hoc.org [150.90.47.226]) by ns.ad-hoc.org (Postfix) with ESMTP id 8298C204062 for ; Mon, 28 Oct 2002 11:59:02 +0900 (JST) Date: Mon, 28 Oct 2002 11:51:50 +0900 Message-ID: From: Kazuhisa TAKEI To: linux-xfs@oss.sgi.com Subject: linvfs_get_dentry patch for 2.5.44 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-vine-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Mon_Oct_28_11:51:50_2002-1" X-archive-position: 1323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: takei@linux.or.jp Precedence: bulk X-list: linux-xfs --Multipart_Mon_Oct_28_11:51:50_2002-1 Content-Type: text/plain; charset=US-ASCII Hi this patch add linvfs_get_dentry to linvfs_set_inode_ops. in 2.5.44 XFS's kernel when dentry is not cached , if detnry is searched using find_export_dentry knfsd will do Oops. this probrem's is the only using NFS. This patch define linvfs_get_dentry and it avoid to perform read_inode. Probrem don't occur if read_inode was defined. Are There reason of removing linvfs_read_inode ? following is Oops case. Test Case: 1. server export server side: # mount -o xfs /dev/sdb1 /testexport # mkdir -k /testexport/a/b/c # exportfs nfsserver:/test 2. mounting in mounting client side: # mount nfsserver:/testexport /mounttest # cd /mounttest/a/b/c 3. reboot server and restart knfsd. ( dont umound in client side) 4. perform 'ls' cmd in client side # ls 5. print Oops in Serverside. Regards. --- Kazuhisa TAKEI --Multipart_Mon_Oct_28_11:51:50_2002-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="xfs-linux25-export.diff" Content-Transfer-Encoding: 7bit ===== xfs_super.c 1.8 vs ? (writable without lock!) ===== --- /tmp/xfs_super.c-1.8-10037 Tue Oct 15 06:10:03 2002 +++ xfs_super.c Thu Oct 24 19:24:50 2002 @@ -531,6 +531,55 @@ linvfs_set_inode_ops( } } +struct dentry * +linvfs_get_dentry(struct super_block *sb, void *vp) +{ + __u32 *data = vp; + vfs_t *vfsp = LINVFS_GET_VFS(sb); + xfs_mount_t *mp = XFS_BHVTOM(vfsp->vfs_fbhv); + ino_t ino = (ino_t)data[0]; /*XXX*/ + __u32 generation = data[1]; /*XXX*/ + struct dentry *result; + struct inode *inode; + xfs_inode_t *ip; + int error; + + error = xfs_iget(mp, NULL, ino, XFS_ILOCK_SHARED, &ip, 0); + if (error) + return ERR_PTR(-error); + if (ip == NULL) + return ERR_PTR(-EIO); + + if (ip->i_d.di_mode == 0) { + result = ERR_PTR(-ENOENT); + goto error_iput; + } + + if (ip->i_d.di_gen != generation) { + result = ERR_PTR(-ENOENT); + goto error_iput; + } + + inode = LINVFS_GET_IP(XFS_ITOV(ip)); + if (inode->i_generation != generation) { + result = ERR_PTR(-ENOENT); + goto error_iput; + } + xfs_iunlock(ip, XFS_ILOCK_SHARED); + + result = d_alloc_anon(inode); + if (!result) { + iput(inode); + return ERR_PTR(-ENOMEM); + } + result->d_vfs_flags |= DCACHE_REFERENCED; + return result; + +error_iput: + xfs_iput_new(ip, XFS_ILOCK_SHARED); + return result; +} + /* * We do not actually write the inode here, just mark the * super block dirty so that sync_supers calls us and @@ -756,6 +805,7 @@ linvfs_get_sb( STATIC struct export_operations linvfs_export_ops = { .get_parent = linvfs_get_parent, + .get_dentry = linvfs_get_dentry, }; STATIC int --Multipart_Mon_Oct_28_11:51:50_2002-1-- From owner-linux-xfs@oss.sgi.com Sun Oct 27 20:10:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 20:10:39 -0800 (PST) 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 g9S4AWuR003987 for ; Sun, 27 Oct 2002 20:10:32 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA59160; Sun, 27 Oct 2002 22:10:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id WAA26432; Sun, 27 Oct 2002 22:10:52 -0600 (CST) Date: Sun, 27 Oct 2002 22:05:39 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: ASANO Masahiro cc: linux-xfs@oss.sgi.com Subject: Re: xfs_syncsub() question In-Reply-To: <20021028114709M.masano@tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1324 X-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, I'll have to look a bit more closely... but your patch does look correct. Back in 2000 (v. 1.279), it was as you suggest, but Steve changed it. :) Steve? (The Irix code also has your "new" test.) Thanks, -Eric On Mon, 28 Oct 2002, ASANO Masahiro wrote: > Hi, > > I have a question. > Why don't we sync the last xfs_inode in xfs_syncsub()? > I am wondering if the condition check is wrong... (see below) > > -- > Masano > > --- linux/fs/xfs/xfs_vfsops.c Thu Oct 24 07:46:17 2002 > +++ linux/fs/xfs/xfs_vfsops.c.new Mon Oct 28 11:29:21 2002 > @@ -1433,7 +1433,7 @@ > ASSERT(ipointer_in == B_FALSE); > ip = ip->i_mnext; > > - } while (ip->i_mnext != mp->m_inodes); > + } while (ip != mp->m_inodes); > > XFS_MOUNT_IUNLOCK(mp); > > > From owner-linux-xfs@oss.sgi.com Sun Oct 27 23:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 23:13:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9S7DluR005591 for ; Sun, 27 Oct 2002 23:13:47 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9S7DlMN005590 for linux-xfs@oss.sgi.com; Sun, 27 Oct 2002 23:13:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9S7DjuX005570 for ; Sun, 27 Oct 2002 23:13:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9S77f1d005509; Sun, 27 Oct 2002 23:07:41 -0800 Date: Sun, 27 Oct 2002 23:07:41 -0800 Message-Id: <200210280707.g9S77f1d005509@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown using NFS X-Bugzilla-Reason: AssignedTo X-archive-position: 1325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 c.pascoe@itee.uq.edu.au changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|xfs_force_shutdown on a lvm |xfs_force_shutdown using NFS |device | ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-27 23:07 ------- Done some more investigation - the system is shutting down the filesystem as xfs_iget is returning EIO (there's only one place it does this) to xfs_trans_iget, which then propagates back to xfs_ialloc and xfs_dir_alloc. Then, once we're back in xfs_create, xfs_mkdir or xfs_symlink, we then jump to the abort_return tag, and the filesystem gets shut down by the subsequent xfs_trans_cancel. I have seen all three of the above functions in kdb backtraces when this has occurred. Hope this helps... Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Oct 27 23:43:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Oct 2002 23:43:50 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9S7hluR008734 for ; Sun, 27 Oct 2002 23:43:47 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9S7hlXP008733 for linux-xfs@oss.sgi.com; Sun, 27 Oct 2002 23:43:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9S7hjuX008713 for ; Sun, 27 Oct 2002 23:43:45 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9S7Jp2n008613; Sun, 27 Oct 2002 23:19:51 -0800 Date: Sun, 27 Oct 2002 23:19:51 -0800 Message-Id: <200210280719.g9S7Jp2n008613@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown using NFS X-Bugzilla-Reason: AssignedTo X-archive-position: 1326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-27 23:19 ------- > xfs_iget is returning EIO (there's only one place it does this) to Of course, by this I mean that it is returning EIO in the place where it sets error = EIO - confirmed with printk's. (I know that xfs_iget_core can return EIO if the filesystem is shutting down at least). Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Oct 28 01:39:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 01:39:40 -0800 (PST) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9S9dZuR009985 for ; Mon, 28 Oct 2002 01:39:36 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g9S9e3l19431 for ; Mon, 28 Oct 2002 18:40:03 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g9S9e1808615 for ; Mon, 28 Oct 2002 18:40:02 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g9S9e1222043 for ; Mon, 28 Oct 2002 18:40:01 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA362 for ; Mon, 28 Oct 2002 18:39:55 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon Oct 28 18:39:54 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g9S9dxb58371 for ; Mon, 28 Oct 2002 18:39:59 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g9S9dxI23991 for ; Mon, 28 Oct 2002 18:39:59 +0900 To: linux-xfs@oss.sgi.com Subject: transaction vec. length X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Informed Management) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021028183959R.masano@tnes.nec.co.jp> Date: Mon, 28 Oct 2002 18:39:59 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 44 X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Hi, I'm inspecting transaction code now. At some minor case, the log size seems possibly become larger than what it means. I think it need to reset the `nbits' variable in following code (xfs_buf_item_format). -- Masano --- linux/fs/xfs/xfs_buf_item.c Thu Oct 24 07:46:16 2002 +++ linux/fs/xfs/xfs_buf_item.c.new Mon Oct 28 17:42:54 2002 @@ -319,30 +319,31 @@ nbits = 1; } else if (xfs_buf_offset(bp, next_bit << XFS_BLI_SHIFT) != (xfs_buf_offset(bp, last_bit << XFS_BLI_SHIFT) + XFS_BLI_CHUNK)) { buffer_offset = first_bit * XFS_BLI_CHUNK; vecp->i_addr = xfs_buf_offset(bp, buffer_offset); vecp->i_len = nbits * XFS_BLI_CHUNK; /* You would think we need to bump the nvecs here too, but we do not * this number is used by recovery, and it gets confused by the boundary * split here * nvecs++; */ vecp++; first_bit = next_bit; last_bit = next_bit; + nbits = 1; } else { last_bit++; nbits++; } } bip->bli_format.blf_size = nvecs; /* * Check to make sure everything is consistent. */ xfs_buf_item_trace("FORMAT NORM", bip); xfs_buf_item_log_check(bip); } /* From owner-linux-xfs@oss.sgi.com Mon Oct 28 05:42:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 05:42:52 -0800 (PST) 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 g9SDgkuR016531 for ; Mon, 28 Oct 2002 05:42:47 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186AAk-0003pI-00; Mon, 28 Oct 2002 13:43:14 +0000 Date: Mon, 28 Oct 2002 13:43:14 +0000 From: Christoph Hellwig To: Kazuhisa TAKEI Cc: linux-xfs@oss.sgi.com Subject: Re: linvfs_get_dentry patch for 2.5.44 Message-ID: <20021028134314.A14372@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 takei@linux.or.jp on Mon, Oct 28, 2002 at 11:51:50AM +0900 X-archive-position: 1328 X-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 Mon, Oct 28, 2002 at 11:51:50AM +0900, Kazuhisa TAKEI wrote: > Hi > > this patch add linvfs_get_dentry to linvfs_set_inode_ops. > > in 2.5.44 XFS's kernel > when dentry is not cached , if detnry is searched using find_export_dentry knfsd will do Oops. > this probrem's is the only using NFS. > This patch define linvfs_get_dentry and it avoid to perform read_inode. > Probrem don't occur if read_inode was defined. I wrote that support some time ago when I started doing 2.5 nfsd testing, and I was sure I commited it - but it's certainly not in the repository. I'm chekcing in my version now which is functionally identical to yours but matches the style used elsewhere in the file a little better. Thanks for the patch anyway. From owner-linux-xfs@oss.sgi.com Mon Oct 28 05:47:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 05:47:42 -0800 (PST) Received: from ursa.xanoptix.com (host-64-65-199-187.man.choiceone.net [64.65.199.187]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SDleuR017203 for ; Mon, 28 Oct 2002 05:47:40 -0800 Received: from nebula.xanoptix.com ([10.20.1.47] helo=xanoptix.com ident=[G+gqd1injEa03hOs69tP6yG0ZHAARpaE])by ursa.xanoptix.comwith smtp(Exim 3.20 #1 (Debian))id 186AFV-0001KW-00for ; Mon, 28 Oct 2002 08:48:09 -0500 Received: from 10.20.1.45 (SquirrelMail authenticated user kend) by webmail with HTTP; Mon, 28 Oct 2002 08:48:08 -0500 (EST) Message-ID: <37230.10.20.1.45.1035812888.squirrel@webmail> Date: Mon, 28 Oct 2002 08:48:08 -0500 (EST) Subject: Reason for delay in inclusion of ACLs to mainstream kernel? From: To: In-Reply-To: <20021028183959R.masano@tnes.nec.co.jp> References: <20021028183959R.masano@tnes.nec.co.jp> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kend@xanoptix.com Precedence: bulk X-list: linux-xfs Howdy, all -- I'm doing some research, and was wondering if anyone can give me a quick-n-dirty summary of why ACLs took so long to be included by Linus. I believe it had to do with elevation of user privs., but I'd prefer to have it from the horse's mouth, as it were. Thanks for any info... -Ken From owner-linux-xfs@oss.sgi.com Mon Oct 28 06:35:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 06:35:50 -0800 (PST) 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 g9SEZiuR018403 for ; Mon, 28 Oct 2002 06:35:44 -0800 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 GAA04437 for ; Mon, 28 Oct 2002 06:36:12 -0800 (PST) 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 g9SEZ55b001032 for ; Mon, 28 Oct 2002 15:35:05 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g9SEZ5F6001031 for linux-xfs@oss.sgi.com; Mon, 28 Oct 2002 15:35:05 +0100 Date: Mon, 28 Oct 2002 15:35:05 +0100 Message-Id: <200210281435.g9SEZ5F6001031@lab343.munich.sgi.com> Subject: TAKE - fix kNFSD operation To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 1330 X-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 Thanks to Kazuhisa TAKEI at NEC for reminding me of this again and submitting an alternative patch. This is a different version I used to test the refcache performance, it goes through VFS_VGET to avoid code duplication and tries to follow the 2.4 linvfs_fh_to_dentry as much as possible. Date: Mon Oct 28 06:32:31 PST 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:131214a linux/fs/xfs/linux/xfs_super.c - 1.238 - implement get_dentry export operation From owner-linux-xfs@oss.sgi.com Mon Oct 28 07:14:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 07:14:54 -0800 (PST) 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 g9SFEnuR019217 for ; Mon, 28 Oct 2002 07:14:49 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA66863; Mon, 28 Oct 2002 09:15:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA47850; Mon, 28 Oct 2002 09:15:13 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9SFAYE20521; Mon, 28 Oct 2002 09:10:34 -0600 Subject: Re: Little questions From: Steve Lord To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021027214706.GA5589@morpheus.matrix.com> References: <20021027214706.GA5589@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 28 Oct 2002 09:10:34 -0600 Message-Id: <1035817834.18751.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2002-10-27 at 15:47, yoros@wanadoo.es wrote: > > Hi, > > I have a few questions about XFS and generic filesystem management. > > The first question is about the creation of sparse files. I want to > learn more and more. Another question is related to the process of > deleting files. How does XFS delete a file?. Does XFS have a list of > extents? (because it is slow when deleting a file that has lots of > extents). > The more extents a file has, the longer it takes to delete it, yes. It is not the amount of space in a file, but the number of extents which matters. I can remove a 4000 extent file in less than 2 second on a 450MHz box here. So, two questions: 1. How slow is a delete for you, how many extents and how long does it take. 2. What version of the software and what hardware and how is your filesystem configured. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Oct 28 07:23:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 07:23:16 -0800 (PST) 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 g9SFNBuR020194 for ; Mon, 28 Oct 2002 07:23:12 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA83441 for ; Mon, 28 Oct 2002 09:23:36 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA14176 for ; Mon, 28 Oct 2002 09:23:35 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9SFIvY21056; Mon, 28 Oct 2002 09:18:57 -0600 Message-Id: <200210281518.g9SFIvY21056@jen.americas.sgi.com> Date: Mon, 28 Oct 2002 09:18:57 -0600 Subject: TAKE - fix some pagebuf I/O completion handling X-archive-position: 1332 X-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 fix from ASANO Masahiro , for the case where we are going to get multiple I/O completions from the driver under pagebuf, set the expected completion count in one go rather than incrementing it as we submit requests. Otherwise we can get multiple I/O completions which get treated as the last one. Date: Mon Oct 28 07:23:11 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131215a linux/fs/xfs/pagebuf/page_buf.c - 1.73 - set psync->remain in one go rather than incrementing it several times. From owner-linux-xfs@oss.sgi.com Mon Oct 28 07:29:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 07:29:28 -0800 (PST) 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 g9SFTQuR020669 for ; Mon, 28 Oct 2002 07:29:26 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA11294; Mon, 28 Oct 2002 09:29:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA09511; Mon, 28 Oct 2002 09:29:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9SFPBj22091; Mon, 28 Oct 2002 09:25:11 -0600 Subject: Re: Reason for delay in inclusion of ACLs to mainstream kernel? From: Steve Lord To: kend@xanoptix.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <37230.10.20.1.45.1035812888.squirrel@webmail> References: <20021028183959R.masano@tnes.nec.co.jp> <37230.10.20.1.45.1035812888.squirrel@webmail> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 28 Oct 2002 09:25:11 -0600 Message-Id: <1035818711.18708.28.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1333 X-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-28 at 07:48, kend@xanoptix.com wrote: > Howdy, all -- I'm doing some research, and was wondering if anyone can > give me a quick-n-dirty summary of why ACLs took so long to be included by > Linus. I believe it had to do with elevation of user privs., but I'd > prefer to have it from the horse's mouth, as it were. > > Thanks for any info... > Quite simply, everyone had a different opinion. Linus was not interested until there was some form of consensus. There were several digressions along the way when Hans Reiser tried to introduce some vast scheme to reinvent filesystems so that files had multiple forks. And truth be known, Linus has not included the code to enable acls yet. Everything is there but the last link in the chain. Extended attributes are there in full though. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Oct 28 07:50:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 07:50:17 -0800 (PST) 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 g9SFoCuR021619 for ; Mon, 28 Oct 2002 07:50:12 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA18542; Mon, 28 Oct 2002 09:50:35 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA60175; Mon, 28 Oct 2002 09:50:35 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9SFp9kq019440; Mon, 28 Oct 2002 09:51:10 -0600 Subject: Re: Here is the results of my last question... From: Russell Cattelan To: Chris Wedgwood Cc: Andi Kleen , yoros@wanadoo.es, linux-xfs In-Reply-To: <20021025194911.GB26998@tapu.f00f.org> References: <20021025181514.GA21940@morpheus.matrix.com> <20021025202727.A2421@wotan.suse.de> <20021025194911.GB26998@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 28 Oct 2002 09:51:08 -0600 Message-Id: <1035820270.3416.4.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1334 X-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-25 at 14:49, Chris Wedgwood wrote: > On Fri, Oct 25, 2002 at 08:27:27PM +0200, Andi Kleen wrote: > > > The right thing would be to change the downloader assistant to use > > XFS' file preallocation ioctls so that it allocates the full space > > in advance. Unfortuately they are not fully implemented on linux/xfs > > and are only available for root currently. I would be possible to > > create the file first and fill it with zeroes. This way you should > > get few extents. > > It would be pretty cheap for the downloader to actually just touch > lseek/touch ahead a few MB of each writer too, this would be almost as > easy to code and would work on other filesystems. That would just create a file with a hole, and holes are filled in the same way appends are filled in. > > > --cw > From owner-linux-xfs@oss.sgi.com Mon Oct 28 07:51:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 07:51:40 -0800 (PST) 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 g9SFpYuR021709 for ; Mon, 28 Oct 2002 07:51:34 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA48672; Mon, 28 Oct 2002 09:51:58 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA64849; Mon, 28 Oct 2002 09:51:57 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9SFqXkq019456; Mon, 28 Oct 2002 09:52:33 -0600 Subject: Re: kernel-2.4.19-SGI_XFS_1.2pre2.src.rpm? From: Russell Cattelan To: Axel Thimm Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021026184746.GA26522@bonzo.nirvana> References: <20021026184746.GA26522@bonzo.nirvana> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 28 Oct 2002 09:52:33 -0600 Message-Id: <1035820353.3414.6.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1335 X-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 Sat, 2002-10-26 at 13:47, Axel Thimm wrote: > The new 1.2pre2 contains kernel-...-2.4.19-SGI_XFS_1.2pre2....rpms, where can > I find the corresponding src.rpm? > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/SRPMS does > not yet contain it. Sorry about that, forgot to push it out. Tis available now. > > Thanks, Axel. > -- > Axel.Thimm@physik.fu-berlin.de > From owner-linux-xfs@oss.sgi.com Mon Oct 28 08:43:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 08:43:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SGhmuR023394 for ; Mon, 28 Oct 2002 08:43:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SGhm6E023392 for linux-xfs@oss.sgi.com; Mon, 28 Oct 2002 08:43:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SGhjuf023353 for ; Mon, 28 Oct 2002 08:43:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SGNO8O023210; Mon, 28 Oct 2002 08:23:24 -0800 Date: Mon, 28 Oct 2002 08:23:24 -0800 Message-Id: <200210281623.g9SGNO8O023210@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown using NFS X-Bugzilla-Reason: AssignedTo X-archive-position: 1337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-10-28 08:23 ------- Chris - unfortunately, due to the way we export to CVS, you can't retrieve files that have been renamed. The closest you could get would be to use the old snapshot patches... -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Oct 28 08:43:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 08:43:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SGhmuR023395 for ; Mon, 28 Oct 2002 08:43:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SGhmNE023393 for linux-xfs@oss.sgi.com; Mon, 28 Oct 2002 08:43:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SGhjud023353 for ; Mon, 28 Oct 2002 08:43:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SGM632023199; Mon, 28 Oct 2002 08:22:06 -0800 Date: Mon, 28 Oct 2002 08:22:06 -0800 Message-Id: <200210281622.g9SGM632023199@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown using NFS X-Bugzilla-Reason: AssignedTo X-archive-position: 1336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-10-28 08:22 ------- Hi Chris - if you can decode the oops you got after you set the panic mask, that would be helpful. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Oct 28 08:54:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 08:54:21 -0800 (PST) Received: from flood.physik.tu-cottbus.de (flood.physik.TU-Cottbus.De [141.43.75.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SGsIuR024316 for ; Mon, 28 Oct 2002 08:54:19 -0800 Received: by flood.physik.tu-cottbus.de (Postfix, from userid 7820) id 81D65701F09; Mon, 28 Oct 2002 17:54:47 +0100 (CET) Date: Mon, 28 Oct 2002 17:54:47 +0100 From: Ionut Georgescu To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown called from line 1042 of xfs_trans.c Message-ID: <20021028165447.GA9766@physik.tu-cottbus.de> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: george@physik.tu-cottbus.de Precedence: bulk X-list: linux-xfs Hi, our server has experienced a pretty bad crash (from the users' point of view) today, after less then 10 hours uptime: Oct 28 10:28:04 flood kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01b2a55 The box: * software: # kernel from the CVS (just checked out yesterday, 27.10.2002) compiled with HIGHMEM = 4GB # Debian stable -> gcc 2.95.4 * hardware: # AthlonMP (1 CPU) with AMD 760MPX chipset and 1 GB RAM # 7 SCSI disks on 2 Adaptec controlers: one system disk, one is exported over NFS, and the other 5 make up a SoftRAID 5 device. The raid device (md0) is not used yet. The shutdown filesystem was the NFS exported one. Unfortunately I can't remember what version of mkfs.xfs I had formatted it with. (I remember there were some issues about 6 months ago). What I had in mind was to reformat the disk with the latest version of xfsprogs. Does this make sense ? I have also read on this list about Andrea's kernels, which have XFS and some pretty important VM patches included (according to http://marc.theaimsgroup.com/?l=linux-xfs&m=101857274727754&w=2 ) What would you suggest ? I have a very good experience with XFS on some workstations, but none with XFS on a server. Thanks a lot, Ionut -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Mon Oct 28 09:04:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 09:05:05 -0800 (PST) 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 g9SH4vuR024918 for ; Mon, 28 Oct 2002 09:04:58 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA55020; Mon, 28 Oct 2002 11:05:21 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA83813; Mon, 28 Oct 2002 11:05:19 -0600 (CST) Subject: Re: xfs_force_shutdown called from line 1042 of xfs_trans.c From: Eric Sandeen To: Ionut Georgescu Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021028165447.GA9766@physik.tu-cottbus.de> References: <20021028165447.GA9766@physik.tu-cottbus.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Oct 2002 11:00:02 -0600 Message-Id: <1035824403.7907.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1339 X-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 Ionut - Unfortunately you're not the only one, please see: http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 The good news is that this seems to be fairly repeatable, and we should be able to find a fix for it... as soon as we can get some resources on the problem. -Eric On Mon, 2002-10-28 at 10:54, Ionut Georgescu wrote: > Hi, > > our server has experienced a pretty bad crash (from the users' point of view) > today, after less then 10 hours uptime: > > Oct 28 10:28:04 flood kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01b2a55 > > The box: > * software: > # kernel from the CVS (just checked out yesterday, 27.10.2002) compiled with > HIGHMEM = 4GB > # Debian stable -> gcc 2.95.4 > * hardware: > # AthlonMP (1 CPU) with AMD 760MPX chipset and 1 GB RAM > # 7 SCSI disks on 2 Adaptec controlers: one system disk, one is > exported over NFS, and the other 5 make up a SoftRAID 5 device. The > raid device (md0) is not used yet. > > The shutdown filesystem was the NFS exported one. Unfortunately I can't > remember what version of mkfs.xfs I had formatted it with. (I remember > there were some issues about 6 months ago). > > What I had in mind was to reformat the disk with the latest version of > xfsprogs. Does this make sense ? > > I have also read on this list about Andrea's kernels, which have XFS > and some pretty important VM patches included (according to > http://marc.theaimsgroup.com/?l=linux-xfs&m=101857274727754&w=2 > ) > > What would you suggest ? I have a very good experience with XFS on > some workstations, but none with XFS on a server. > > Thanks a lot, > Ionut > > > -- > *************** > * Ionut Georgescu > * http://www.physik.tu-cottbus.de/~george/ > * Registered Linux User #244479 > * > * "In Windows you can do everything Microsoft wants you to do; in Unix you > * can do anything the computer is able to do." > -- 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 28 09:05:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 09:05:37 -0800 (PST) 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 g9SH5XuR025000 for ; Mon, 28 Oct 2002 09:05:33 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA96100 for ; Mon, 28 Oct 2002 11:05:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA41798 for ; Mon, 28 Oct 2002 11:05:56 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9SH1HA23706; Mon, 28 Oct 2002 11:01:17 -0600 Message-Id: <200210281701.g9SH1HA23706@jen.americas.sgi.com> Date: Mon, 28 Oct 2002 11:01:17 -0600 Subject: TAKE - fix some log formatting code X-archive-position: 1340 X-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 fix from ASANO Masahiro . In calculating the layout of a log record for a buffer, the linux code deals with buffers which are not contiguous in memory - this only applies to an inode buffer. This adds one more fragmentation case to the code, and a line was missing from this. The end result would be the logging of too much data if this was not the last component of the buffer. The code was definitely wrong, but I think the chances of hitting this were pretty slim, and the resulting error would only matter if there was a crash shortly afterward. Date: Mon Oct 28 09:05:38 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131221a linux/fs/xfs/xfs_buf_item.c - 1.132 - reset nbits when starting a new log vector record. From owner-linux-xfs@oss.sgi.com Mon Oct 28 09:13:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 09:13:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SHDmuR025941 for ; Mon, 28 Oct 2002 09:13:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SHDlwO025940 for linux-xfs@oss.sgi.com; Mon, 28 Oct 2002 09:13:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9SHDjuX025920 for ; Mon, 28 Oct 2002 09:13:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9SH36NO024895; Mon, 28 Oct 2002 09:03:06 -0800 Date: Mon, 28 Oct 2002 09:03:06 -0800 Message-Id: <200210281703.g9SH36NO024895@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|xfs_force_shutdown using NFS|xfs_force_shutdown in | |xfs_trans_cancel ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Oct 28 09:15:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 09:15:43 -0800 (PST) Received: from flood.physik.tu-cottbus.de (flood.physik.TU-Cottbus.De [141.43.75.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SHFeuR026323 for ; Mon, 28 Oct 2002 09:15:41 -0800 Received: by flood.physik.tu-cottbus.de (Postfix, from userid 7820) id 9BEEC701F09; Mon, 28 Oct 2002 18:16:09 +0100 (CET) Date: Mon, 28 Oct 2002 18:16:09 +0100 From: Ionut Georgescu To: linux-xfs@oss.sgi.com Subject: already in bugzilla: xfs_force_shutdown called from line 1042 of xfs_trans.c Message-ID: <20021028171609.GA10590@physik.tu-cottbus.de> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: george@physik.tu-cottbus.de Precedence: bulk X-list: linux-xfs Forgot to include the whole log entry: Oct 28 10:28:04 flood kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01b2a55 Oct 28 10:28:04 flood kernel: Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Oct 28 10:28:04 flood kernel: Please umount the filesystem, and rectify the problem(s) ... ... Just seen that it has already been reported with bugzilla. I think I'll submit a 'me too'. Ionut -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix you * can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Mon Oct 28 11:40:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 11:40:20 -0800 (PST) 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 g9SJeIuR028721 for ; Mon, 28 Oct 2002 11:40:18 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 8C83B1EE471; Mon, 28 Oct 2002 11:40:46 -0800 (PST) Date: Mon, 28 Oct 2002 11:40:46 -0800 From: Chris Wedgwood To: Russell Cattelan Cc: Andi Kleen , yoros@wanadoo.es, linux-xfs Subject: Re: Here is the results of my last question... Message-ID: <20021028194046.GA27749@tapu.f00f.org> References: <20021025181514.GA21940@morpheus.matrix.com> <20021025202727.A2421@wotan.suse.de> <20021025194911.GB26998@tapu.f00f.org> <1035820270.3416.4.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1035820270.3416.4.camel@rose.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1343 X-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 28, 2002 at 09:51:08AM -0600, Russell Cattelan wrote: > That would just create a file with a hole, and holes are filled in > the same way appends are filled in. Obviously you fill from start to end ... one pass, not per-reader/writer. --cw From owner-linux-xfs@oss.sgi.com Mon Oct 28 13:29:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 13:29:38 -0800 (PST) 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 g9SLTXuR031061 for ; Mon, 28 Oct 2002 13:29:35 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA31873; Mon, 28 Oct 2002 15:29:59 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA75342; Mon, 28 Oct 2002 15:29:58 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9SLPHc03046; Mon, 28 Oct 2002 15:25:17 -0600 Subject: Re: xfs_syncsub() question From: Steve Lord To: Eric Sandeen Cc: ASANO Masahiro , 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: 28 Oct 2002 15:25:17 -0600 Message-Id: <1035840317.2570.512.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2002-10-27 at 22:05, Eric Sandeen wrote: > Hi, I'll have to look a bit more closely... but your patch does look correct. > Back in 2000 (v. 1.279), it was as you suggest, but Steve changed it. > :) Steve? I no longer remember the why of this change, I think we can just revert to this code. Steve > > (The Irix code also has your "new" test.) > > Thanks, > > -Eric > > On Mon, 28 Oct 2002, ASANO Masahiro wrote: > > > Hi, > > > > I have a question. > > Why don't we sync the last xfs_inode in xfs_syncsub()? > > I am wondering if the condition check is wrong... (see below) > > > > -- > > Masano > > > > --- linux/fs/xfs/xfs_vfsops.c Thu Oct 24 07:46:17 2002 > > +++ linux/fs/xfs/xfs_vfsops.c.new Mon Oct 28 11:29:21 2002 > > @@ -1433,7 +1433,7 @@ > > ASSERT(ipointer_in == B_FALSE); > > ip = ip->i_mnext; > > > > - } while (ip->i_mnext != mp->m_inodes); > > + } while (ip != mp->m_inodes); > > > > XFS_MOUNT_IUNLOCK(mp); > > > > > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Oct 28 13:29:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 13:29:31 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SLTSuR031060 for ; Mon, 28 Oct 2002 13:29:28 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9SLTwA11128 for ; Mon, 28 Oct 2002 16:29:58 -0500 Message-ID: <3DBDAC4A.40001@ksimachine.com> Date: Mon, 28 Oct 2002 16:29:46 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: patch howto??? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs I have a couple of systems I a running RH 7.2 - using the XFS 2.4.9-31 kernel I would like to update these systems to 2.4.18-17.7, and need to merge in the XFS bits. Does anyone know of a good howto to patch and create a RedHat kernel RPMs? The last kernels I have compiled was on a Slackware system. Thanks, -- Joseph St.Clair From owner-linux-xfs@oss.sgi.com Mon Oct 28 13:49:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 13:50:01 -0800 (PST) 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 g9SLnquR032064 for ; Mon, 28 Oct 2002 13:49:54 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA48254; Mon, 28 Oct 2002 15:50:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA17527; Mon, 28 Oct 2002 15:50:17 -0600 (CST) Subject: Re: patch howto??? From: Eric Sandeen To: ksimach@ksimachine.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DBDAC4A.40001@ksimachine.com> References: <3DBDAC4A.40001@ksimachine.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 28 Oct 2002 15:44:58 -0600 Message-Id: <1035841498.8560.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1346 X-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 Patching Red Hat (or other vendor kernels) is tough, and non-trivial. In general, you only want to use a patch against the codebase it was generated from. We have patches against "vanilla" linux kernels from Linus & Marcello, and instructions for using these patches are at http://oss.sgi.com/projects/xfs/source.html We also have some prerelease kernel RPMs based on Red Hat 8.0 / 2.4.18-17 kernels, at ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/RPMS/ -Eric On Mon, 2002-10-28 at 15:29, Joe St.Clair wrote: > I have a couple of systems I a running RH 7.2 - using the XFS 2.4.9-31 > kernel > > I would like to update these systems to 2.4.18-17.7, and need to merge > in the XFS bits. > > Does anyone know of a good howto to patch and create a RedHat kernel RPMs? > > The last kernels I have compiled was on a Slackware system. > > Thanks, > -- > Joseph St.Clair > > -- 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 28 14:05:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 14:05:09 -0800 (PST) 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 g9SM4xuR032662 for ; Mon, 28 Oct 2002 14:05:00 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186I0k-0008JQ-00; Mon, 28 Oct 2002 22:05:26 +0000 Date: Mon, 28 Oct 2002 22:05:25 +0000 From: Christoph Hellwig To: Steve Lord Cc: Eric Sandeen , ASANO Masahiro , linux-xfs@oss.sgi.com Subject: Re: xfs_syncsub() question Message-ID: <20021028220525.A31860@infradead.org> References: <1035840317.2570.512.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1035840317.2570.512.camel@jen.americas.sgi.com>; from lord@sgi.com on Mon, Oct 28, 2002 at 03:25:17PM -0600 X-archive-position: 1347 X-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 Mon, Oct 28, 2002 at 03:25:17PM -0600, Steve Lord wrote: > On Sun, 2002-10-27 at 22:05, Eric Sandeen wrote: > > Hi, I'll have to look a bit more closely... but your patch does look correct. > > Back in 2000 (v. 1.279), it was as you suggest, but Steve changed it. > > :) Steve? > > I no longer remember the why of this change, I think we can just revert > to this code. Whem I look at the diff at http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=1.279&r2=1.280 I don't know either what your rationale for this was, but it seems we need to revert the ip = ip->i_mnext assignment before the continue statements then. Still trying to understand that commit, especially as the commit message isn't exactly helpfull.. > > Steve > > > > > (The Irix code also has your "new" test.) > > > > Thanks, > > > > -Eric > > > > On Mon, 28 Oct 2002, ASANO Masahiro wrote: > > > > > Hi, > > > > > > I have a question. > > > Why don't we sync the last xfs_inode in xfs_syncsub()? > > > I am wondering if the condition check is wrong... (see below) > > > > > > -- > > > Masano > > > > > > --- linux/fs/xfs/xfs_vfsops.c Thu Oct 24 07:46:17 2002 > > > +++ linux/fs/xfs/xfs_vfsops.c.new Mon Oct 28 11:29:21 2002 > > > @@ -1433,7 +1433,7 @@ > > > ASSERT(ipointer_in == B_FALSE); > > > ip = ip->i_mnext; > > > > > > - } while (ip->i_mnext != mp->m_inodes); > > > + } while (ip != mp->m_inodes); > > > > > > XFS_MOUNT_IUNLOCK(mp); > > > > > > > > > > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > ---end quoted text--- From owner-linux-xfs@oss.sgi.com Mon Oct 28 14:06:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 14:06:31 -0800 (PST) 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 g9SM6RuR000357 for ; Mon, 28 Oct 2002 14:06:28 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186I2A-0008JZ-00; Mon, 28 Oct 2002 22:06:54 +0000 Date: Mon, 28 Oct 2002 22:06:54 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: patch howto??? Message-ID: <20021028220654.B31860@infradead.org> References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1035841498.8560.17.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Mon, Oct 28, 2002 at 03:44:58PM -0600 X-archive-position: 1348 X-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 Mon, Oct 28, 2002 at 03:44:58PM -0600, Eric Sandeen wrote: > Patching Red Hat (or other vendor kernels) is tough, and non-trivial. > > In general, you only want to use a patch against the codebase it was > generated from. > > We have patches against "vanilla" linux kernels from Linus & Marcello, > and instructions for using these patches are at > http://oss.sgi.com/projects/xfs/source.html > > We also have some prerelease kernel RPMs based on Red Hat 8.0 / > 2.4.18-17 kernels, at > ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/RPMS/ Note that 2.4.18-17.7x is also the recommend errata kernel ofor RH7.x, so if you want RedHat's latest updates _and_ XFS use the kernel Eric pointed you to.. From owner-linux-xfs@oss.sgi.com Mon Oct 28 14:10:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 14:10:56 -0800 (PST) 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 g9SMAruR001208 for ; Mon, 28 Oct 2002 14:10:53 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186I6S-0008Nh-00; Mon, 28 Oct 2002 22:11:20 +0000 Date: Mon, 28 Oct 2002 22:11:20 +0000 From: Christoph Hellwig To: Steve Lord Cc: Eric Sandeen , ASANO Masahiro , linux-xfs@oss.sgi.com Subject: Re: xfs_syncsub() question Message-ID: <20021028221120.A32216@infradead.org> References: <1035840317.2570.512.camel@jen.americas.sgi.com> <20021028220525.A31860@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: <20021028220525.A31860@infradead.org>; from hch@infradead.org on Mon, Oct 28, 2002 at 10:05:25PM +0000 X-archive-position: 1349 X-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 Mon, Oct 28, 2002 at 10:05:25PM +0000, Christoph Hellwig wrote: > I don't know either what your rationale for this was, but it seems we need > to revert the ip = ip->i_mnext assignment before the continue statements then. Umm, no - thinko. From owner-linux-xfs@oss.sgi.com Mon Oct 28 14:18:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 14:18:56 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SMIpuR001676 for ; Mon, 28 Oct 2002 14:18:51 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9SMJLA13260 for ; Mon, 28 Oct 2002 17:19:21 -0500 Message-ID: <3DBDB7DE.60007@ksimachine.com> Date: Mon, 28 Oct 2002 17:19:10 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: patch howto??? References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> <20021028220654.B31860@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Thanks Christoph, I will give it a try. Christoph Hellwig wrote: >Note that 2.4.18-17.7x is also the recommend errata kernel ofor RH7.x, >so if you want RedHat's latest updates _and_ XFS use the kernel Eric >pointed you to.. > > > -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Mon Oct 28 14:57:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 14:57:59 -0800 (PST) Received: from morpheus.matrix.com (193-152-139-22.uc.nombres.ttd.es [193.152.139.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SMuQuR002979 for ; Mon, 28 Oct 2002 14:57:11 -0800 Received: (qmail 12603 invoked by uid 1000); 28 Oct 2002 22:51:13 -0000 From: yoros@wanadoo.es Date: Mon, 28 Oct 2002 23:51:13 +0100 To: linux-xfs Subject: Re: Little questions Message-ID: <20021028225113.GA12476@morpheus.matrix.com> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <1035817834.18751.24.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --ibTvN161/egqYuK8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 28, 2002 at 09:10:34AM -0600, Steve Lord wrote: > On Sun, 2002-10-27 at 15:47, yoros@wanadoo.es wrote: > >=20 > > Hi, > >=20 > > I have a few questions about XFS and generic filesystem management. > >=20 > > The first question is about the creation of sparse files. I want to > > learn more and more. Another question is related to the process of > > deleting files. How does XFS delete a file?. Does XFS have a list of > > extents? (because it is slow when deleting a file that has lots of > > extents). > >=20 >=20 > The more extents a file has, the longer it takes to delete it, yes. > It is not the amount of space in a file, but the number of extents > which matters. I can remove a 4000 extent file in less than 2 second > on a 450MHz box here. >=20 > So, two questions: >=20 > 1. How slow is a delete for you, how many extents and how long > does it take. >=20 > 2. What version of the software and what hardware and how is > your filesystem configured. Yes, I know that the files I'm deleting has a lot of extents but I also know that other filesystems are faster deleting files. Yes, I can understand that XFS must to "delete" some blocks that contains metadata for the extents (B trees or the other structure) but I think that this "deletion" can be done more quick or just try to get allways unfragmented filesystem. These are only a few ideas that are going through my head. Now I have the technical documents about XFS and I am learning more and more. See you, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9vb9hWIvihXTx06wRAr16AJ9xfUtK8ZC2Fbn7lsj1nd23820eXACgrU6A MWiyARw1HHP2D249iLM4yKM= =5UPD -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-linux-xfs@oss.sgi.com Mon Oct 28 15:26:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 15:26:08 -0800 (PST) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SNQ3uR012894 for ; Mon, 28 Oct 2002 15:26:03 -0800 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9SNPcf18631; Mon, 28 Oct 2002 18:25:38 -0500 Message-ID: <3DBDC774.3D1D1157@splentec.com> Date: Mon, 28 Oct 2002 18:25:40 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: ASANO Masahiro , linux-xfs@oss.sgi.com Subject: Re: fix 2.4-xfs pagebuf request References: <20021027161351Z.masano@tnes.nec.co.jp> <20021027153520.A21019@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Sun, Oct 27, 2002 at 04:13:51PM +0900, ASANO Masahiro wrote: > > Hi, > > > > I found a bug at current 2.4 CVS about `struct pagesync_t'. > > Some driver top-half may call buffer_head.b_end_io() on process > > context (not interrupt context). So _end_pagebuf_page_io_multi() may > > be called several times with remain==1. > > Thanks for the patch. Luben, I think this patch will fix your > lvm+raid setup, could you try it? Yes, that was it all along... (BTW, I'm using a different patch, see last sentences of this message.) Oh well, what can I say... A classical synchronization (race) bug. Relying on plug/unplug device, as shown, would eventually lead to races on stacking drivers... I'd recommend a detailed look at drivers/md/raid1.c::raid1_make_request() for a clear view of how bh's should be submitted and which bits of b_state should and should NOT be set. This is to be considered of dire importance for this enterprise product. Also, there's a long comment describing exactly those kinds of races there... I'd recommend pulling generic_make_request() out of that loop and putting it into its own loop with just one purpose -- submitting the bh's. And calling run_task_queue(&tq_disk) _right_ after ALL the bh's have been submitted, for performance issues. (Become my hero -- submit a patch for the above.) Ironically, ``sbs'' does exactly that (but with no races of course), so this is why it worked when put in the middle. Also, it is unbelievable to have a pagesync_t structure whose meaning is implicit by just a single atomic variable, and at the same time pass around a locking variable as an int! If any locking is implied by it, it should be _at_least_ declared volatile and a pointer to it passed around. (It's ironic the name pagesync_t and by the use of it to miss it's only existence -- synchronization... don't you think?) Furthermore a function with 9 arguments has no place in a kernel. This cries for a structure of its own. Constructs like this: if (a) { statements1; goto request; } statements2; request: statements3; clearly show this was added as an afterthought, rather than the initial would be design: if (a) { statements1; } else { statements2; } /* request: */ statements3; Nevertheless, thanks to Asano Masahiro, now mount no longer goes in D when the setup is xfs->lvm->md->scsi disks, and bug 182 _seems_ to be resolved. (BTW, I'm using a slightly different patch as described in this letter (b_state bits different, generic_make_request() out of loop, run task queue after, etc).) Thanks Asano, -- Luben From owner-linux-xfs@oss.sgi.com Mon Oct 28 23:19:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 23:19:32 -0800 (PST) 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 g9T7JTuR013267 for ; Mon, 28 Oct 2002 23:19:30 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id BBA59AC3D; Tue, 29 Oct 2002 08:14:23 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 4B508190C4; Tue, 29 Oct 2002 08:14:22 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 19BCB30881D; Tue, 29 Oct 2002 08:19:58 +0100 (CET) Message-ID: <3DBE369D.DEAA0608@ch.sauter-bc.com> Date: Tue, 29 Oct 2002 08:19:57 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Christoph Hellwig Cc: Eric Sandeen , ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: patch howto??? References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> <20021028220654.B31860@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1353 X-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 Christoph Hellwig schrieb: > > On Mon, Oct 28, 2002 at 03:44:58PM -0600, Eric Sandeen wrote: > > Patching Red Hat (or other vendor kernels) is tough, and non-trivial. > > > > In general, you only want to use a patch against the codebase it was > > generated from. > > > > We have patches against "vanilla" linux kernels from Linus & Marcello, > > and instructions for using these patches are at > > http://oss.sgi.com/projects/xfs/source.html > > > > We also have some prerelease kernel RPMs based on Red Hat 8.0 / > > 2.4.18-17 kernels, at > > ftp://oss.sgi.com/projects/xfs/download/Release-1.2pre2/kernel_rpms/RPMS/ > > Note that 2.4.18-17.7x is also the recommend errata kernel ofor RH7.x, > so if you want RedHat's latest updates _and_ XFS use the kernel Eric > pointed you to.. Just for the archives... I've installed the kernels mentioned above on several RH 7.2 servers. It has worked - like before - very well. The only problem I had was when upgrading my laptop. The PCMCIA stuff seems broken somehow and unloading kernel modules of PCMCIA devices just crashes the box. I'm sure the problem is that those new kernels were built on RedHat 8.0 which is quite different from 7.x. I then tried to rebuild from source RPM on RedHat 7.2. Building i386 and i586 packages went fine but i686 didn't. I'm happy anyway and thanks for the great product! Simon From owner-linux-xfs@oss.sgi.com Mon Oct 28 23:30:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Oct 2002 23:30:23 -0800 (PST) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T7UGuR014164 for ; Mon, 28 Oct 2002 23:30:19 -0800 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9T7Uhf27077 for ; Tue, 29 Oct 2002 02:30:43 -0500 Message-ID: <3DBE3924.22B019A1@splentec.com> Date: Tue, 29 Oct 2002 02:30:44 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: [PATCH] page_buf stuff Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Maybe like this? --- linux/fs/xfs/pagebuf/page_buf.c.orig Tue Oct 29 01:48:57 2002 +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 29 01:52:17 2002 @@ -1665,22 +1665,18 @@ bh = bufferlist[i]; /* Complete the buffer_head, then submit the IO */ - if (psync) { - init_buffer(bh, callback, psync); - } else { - init_buffer(bh, callback, pb); - } + init_buffer(bh, callback, psync ? : pb); bh->b_rdev = bh->b_dev; bh->b_rsector = bh->b_blocknr; set_bit(BH_Mapped, &bh->b_state); set_bit(BH_Req, &bh->b_state); - - if (rw == WRITE) { - set_bit(BH_Uptodate, &bh->b_state); - } - generic_make_request(rw, bh); + if (rw == WRITE) + set_bit(BH_Dirty, &bh->b_state); } + for (i = 0; i < cnt; i++) + generic_make_request(rw, bufferlist[i]); + run_task_queue(&tq_disk); } else { if (locking) unlock_page(page); From owner-linux-xfs@oss.sgi.com Tue Oct 29 04:13:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 04:13:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9TCDmuR020452 for ; Tue, 29 Oct 2002 04:13:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9TCDmUj020451 for linux-xfs@oss.sgi.com; Tue, 29 Oct 2002 04:13:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9TCDkuX020431 for ; Tue, 29 Oct 2002 04:13:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9TBqX1U019814; Tue, 29 Oct 2002 03:52:33 -0800 Date: Tue, 29 Oct 2002 03:52:33 -0800 Message-Id: <200210291152.g9TBqX1U019814@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-10-29 03:52 ------- Created an attachment (id=44) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=44&action=view) oops/backtrace/transaction ptr dump Hi, a kdb backtrace and transaction dump I found in a console log is attached. This shutdown/oops is the result of the second is_bad_inode(inode) check in xfs_iget tripping and EIO being returned. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 29 05:13:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 05:13:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9TDDmuR021410 for ; Tue, 29 Oct 2002 05:13:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9TDDm76021409 for linux-xfs@oss.sgi.com; Tue, 29 Oct 2002 05:13:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9TDDjuX021389 for ; Tue, 29 Oct 2002 05:13:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9TCviUw021208; Tue, 29 Oct 2002 04:57:44 -0800 Date: Tue, 29 Oct 2002 04:57:44 -0800 Message-Id: <200210291257.g9TCviUw021208@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From lord@sgi.com 2002-10-29 04:57 ------- The use of make_bad_inode in xfs is going to have to be removed somehow, basically what is happening is that the sync activity is using vn_get on an inode which is being torn down. This creates a bad inode which it then tears down. If xfs_iget is being called on the same inode number at the same time, it is getting the bad inode, and returning EIO. This is happening in a create path which is not expecting this type of failure. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 29 05:47:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 05:47:43 -0800 (PST) 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 g9TDleuR022507 for ; Tue, 29 Oct 2002 05:47:40 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA99405; Tue, 29 Oct 2002 07:48:08 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-57.corp.sgi.com [134.15.64.57]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA39980; Tue, 29 Oct 2002 07:48:04 -0600 (CST) Subject: Re: [PATCH] page_buf stuff From: Stephen Lord To: Luben Tuikov Cc: linux-xfs In-Reply-To: <3DBE3924.22B019A1@splentec.com> References: <3DBE3924.22B019A1@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 29 Oct 2002 07:43:33 -0600 Message-Id: <1035899015.9794.13.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1357 X-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-29 at 01:30, Luben Tuikov wrote: > Maybe like this? > > --- linux/fs/xfs/pagebuf/page_buf.c.orig Tue Oct 29 01:48:57 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 29 01:52:17 2002 > @@ -1665,22 +1665,18 @@ > bh = bufferlist[i]; > > /* Complete the buffer_head, then submit the IO */ > - if (psync) { > - init_buffer(bh, callback, psync); > - } else { > - init_buffer(bh, callback, pb); > - } > + init_buffer(bh, callback, psync ? : pb); > Well that's a little cryptic, a conditional expression which I have to deduce is defaulting to the left hand side in the case where there is no right hand side. > bh->b_rdev = bh->b_dev; > bh->b_rsector = bh->b_blocknr; > set_bit(BH_Mapped, &bh->b_state); > set_bit(BH_Req, &bh->b_state); > - > - if (rw == WRITE) { > - set_bit(BH_Uptodate, &bh->b_state); > - } > - generic_make_request(rw, bh); > + if (rw == WRITE) > + set_bit(BH_Dirty, &bh->b_state); In general callers of the block layer clear the dirty bit on buffers they submit, see __block_write_full_page. In reality, since we use generic_make_request it does not appear these flags matter. > } > + for (i = 0; i < cnt; i++) > + generic_make_request(rw, bufferlist[i]); On the one hand you are doing fancy optimizations of the init_buffer call, and on the other you add a new loop - which is not needed once the other synchronization calls are in. > + run_task_queue(&tq_disk); ^^^^^^^^^ This makes XFS more synchronous in terms of disk I/O than it needs to be. Try feeding this code a large dbench load or something similar. > } else { > if (locking) > unlock_page(page); > I think the only part of this which makes a difference to the execution of the code is the run_task_queue, please explain why it is in there. This means xfs has no way to coalesce any metadata I/O beyond an individual page into the device queue. So our 32K log writes become 8 seperate disk I/Os for starters. Now, if you are sitting on top of lvm it is probably slicing and dicing under the covers and masking this, if you try a single disk I think you will notice a performance drop. Steve From owner-linux-xfs@oss.sgi.com Tue Oct 29 09:13:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 09:13:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9THDmuR010256 for ; Tue, 29 Oct 2002 09:13:48 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9THDm7T010255 for linux-xfs@oss.sgi.com; Tue, 29 Oct 2002 09:13:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g9THDkuX010235 for ; Tue, 29 Oct 2002 09:13:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g9TH95mr010176; Tue, 29 Oct 2002 09:09:05 -0800 Date: Tue, 29 Oct 2002 09:09:05 -0800 Message-Id: <200210291709.g9TH95mr010176@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-10-29 09:09 ------- Ok, let's try this. I semi-backported the "ilookup" functions from 2.5, which do the same as iget_locked, but they don't create a new inode. This should remove the need to try to "back out" of an inode creation. The drawback is that it's more of a core kernel change. I'll poke around a bit more and see if there's a more self-contained solution, but I think the above method is the best way to go. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:07:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:07:26 -0800 (PST) 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 g9TJ7LuR018101 for ; Tue, 29 Oct 2002 11:07:22 -0800 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) 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 LAA06967 for ; Tue, 29 Oct 2002 11:07:56 -0800 (PST) mail_from (clambert@sgi.com) Received: from mtv-vpn-hw-clambert-1.corp.sgi.com (onyx4@mtv-vpn-hw-clambert-1.corp.sgi.com [134.15.23.234]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA18895; Tue, 29 Oct 2002 11:07:19 -0800 (PST) Date: Tue, 29 Oct 2002 11:07:18 -0800 (PST) From: Christian Lambert X-X-Sender: clambert@onyx4.dhs.org To: Eric Sandeen cc: linux-xfs@oss.sgi.com, Christian Lambert Subject: Re: 2.4.19xfs + preempt causes hangs? In-Reply-To: <1034615162.2893.12.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clambert@sgi.com Precedence: bulk X-list: linux-xfs I now disabled pre-empt, and basically the only kernel patch I added was supermount+ O(1) batch scheduler and -aa vm patch. Now the problem seems to be different. If a process writes large files (about 1 or 2 gigs) it will often hangs right when it reach the end of the file and it was about to update the directory entry, it just hangs there. Top shows 100% system usage (0% user) and I can't kill the process until it unhangs itself which takes about 2-3 minutes. I'm using the 2.4.19 snapshot, but I just saw that you have a 1.2 pre-release for 2.4.19, so I'm going to recompile my kernel with that and just supermount. I'm also using vmware (which has kernel modules) so i'm not sure if that has an impact or not, but I thought I'd mention it. I could reproduce it often but just doing a "cp -a dir1 dir2" with a couple of 1 gig files in it. -Christian On 14 Oct 2002, Eric Sandeen wrote: | Hi Christian - | | I don't have a lot of experience with pre-empt, but the best thing to do | would be to break into KDB and see which process is hung, and what it's | hung on... if you have kdb.... | | -Eric | | On Mon, 2002-10-14 at 12:00, Christian Lambert wrote: | > | > I've been running a stock debian 2.4.19 + xfs2.4.19 snapshot patch + preempt | > and this worked fine for like 3-4 days now. But this morning I came up | > and my system hung up when I did "ls" in the console. Then everything | > hung up from there and lead eventually to X hanging as well, the hard drive | > light was solid "on". I have a mix of reiserfs and xfs filesystems so I'm | > not sure what caused it, but I wanted to know if this is known to cause | > problems or it's supposed to work? I'm not using lock-break, just preempt. | > I think what might have trigged this hang is the updatedb (for locate) that | > ran during the night and maybe have hosed things up scanning thru the | > filesystems. | > | > -Christian | > | > | -- | 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 29 11:14:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:14:05 -0800 (PST) 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 g9TJE4uR018571 for ; Tue, 29 Oct 2002 11:14:04 -0800 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CA792FF0E for ; Tue, 29 Oct 2002 11:14:38 -0800 (PST) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id D03F62FF0E for ; Tue, 29 Oct 2002 11:14:37 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 6031A1967B for ; Tue, 29 Oct 2002 11:14:27 -0800 (PST) Subject: Re: XFS Logs on Another Device From: Florin Andrei To: linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 29 Oct 2002 11:14:27 -0800 Message-Id: <1035918867.10119.17.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 1360 X-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-25 at 19:23, Eric Sandeen wrote: > > Yes, the external log needs it's own partition, on any disk. I suppose > a whole disk might work, but that would be a horrible waste of space. :) I guess it depends on how crazy you are for performance. ;-) -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:33:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:33:42 -0800 (PST) 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 g9TJXeuR019865 for ; Tue, 29 Oct 2002 11:33:40 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA98236; Tue, 29 Oct 2002 13:34:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA41481; Tue, 29 Oct 2002 13:34:09 -0600 (CST) Date: Tue, 29 Oct 2002 13:28:41 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Christian Lambert cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19xfs + preempt causes hangs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1361 X-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 Christian - Reproducing this with the stock kernel & stock patches (preferably the 1.2-pre patches) would be most helpful, isolating bugs with the patch-set-du-jour can be rough. If you can't reproduce it with the stock kernel, add the patches one at a time and see where things fall apart. -Eric On Tue, 29 Oct 2002, Christian Lambert wrote: > > I now disabled pre-empt, and basically the only kernel patch > I added was supermount+ O(1) batch scheduler and -aa vm patch. Now the problem > seems to be different. If a process writes large files (about 1 or 2 gigs) > it will often hangs right when it reach the end of the file and it was > about to update the directory entry, it just hangs there. Top shows 100% > system usage (0% user) and I can't kill the process until it unhangs itself > which takes about 2-3 minutes. I'm using the 2.4.19 snapshot, but I just > saw that you have a 1.2 pre-release for 2.4.19, so I'm going to recompile > my kernel with that and just supermount. I'm also using vmware (which has > kernel modules) so i'm not sure if that has an impact or not, but I thought I'd > mention it. I could reproduce it often but just doing a "cp -a dir1 dir2" > with a couple of 1 gig files in it. > From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:38:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:38:58 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1ed.dsl.mediaWays.net [213.20.225.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TJctuR020653 for ; Tue, 29 Oct 2002 11:38:56 -0800 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 186cCu-0006N9-00; Tue, 29 Oct 2002 20:39:20 +0100 Message-ID: <3DBEE3E7.7090402@berdmann.de> Date: Tue, 29 Oct 2002 20:39:19 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: David Lloyd , linux-xfs@oss.sgi.com Subject: Re: XFS Logs on Another Device References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs > Yes, the external log needs it's own partition, on any disk. I suppose > a whole disk might work, but that would be a horrible waste of space. :) LVM is very cool for things like this. Just define a 8-12 MB Logical Volume on another disk (Physical Volume) and use it for the log device. From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:40:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:40:48 -0800 (PST) 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 g9TJejuR020820 for ; Tue, 29 Oct 2002 11:40:46 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 6E9D61EE8CB; Tue, 29 Oct 2002 11:41:20 -0800 (PST) Date: Tue, 29 Oct 2002 11:41:20 -0800 From: Chris Wedgwood To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: Here is the results of my last question... Message-ID: <20021029194120.GA5708@tapu.f00f.org> References: <20021025181514.GA21940@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025181514.GA21940@morpheus.matrix.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1363 X-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 25, 2002 at 08:15:14PM +0200, yoros@wanadoo.es wrote: > I have experienced that using one downloader assistant (that creates > a big sparse file an then fill it to complete download), I get a > file with lots of extents sized from 24 to 80 blocks... Yes, I must > run xfs_fsr after download, but it is interesant to include this > performance to the core code... What is this 'download assistant' --- where can I get this to test with? Thanks, --cw From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:46:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:46:30 -0800 (PST) Received: from jsc-ems-vws03.jsc.nasa.gov (jsc-ems-vws03.jsc.nasa.gov [139.169.39.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TJkSuR021553 for ; Tue, 29 Oct 2002 11:46:28 -0800 Received: from 139.169.16.60 by jsc-ems-vws03.jsc.nasa.gov (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 13:47:02 -0600 Received: by jsc-smtp02.jsc.nasa.gov with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 13:47:02 -0600 Message-ID: From: "GIFFORD, ALAN (JSC-SF1) (JEC)" To: "'linux-xfs@oss.sgi.com'" Subject: Can't get my xfs partition to mount Date: Tue, 29 Oct 2002 13:46:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alan.gifford1@jsc.nasa.gov Precedence: bulk X-list: linux-xfs I have an externel SCSI hard drive that I'd like to mount under Linux. I'm using kernel 2.4.19, and I have File systems --> Partition types --> SGI partition support compiled into the kernel, yet when I try to mount like this: mount -t xfs /dev/sdb1 /mnt/sdb/ mount returns that xfs is not supported by the kernel. Unless the kernel make screwed up, this has got to be wrong, because all the other stuff I compiled into the kernel works. It's not even an option to compile it as a module, so that can't be the problem. I did an fdisk /dev/sdb and looked at the partition table. It has three partitions listed, everything looks fine, it has an SGI xfs, SGI volhdr and SGI volume partitions listed. This drive worked on the O2 I just took it off of, so I don't see what the problem is. Thanks in advance for any help you can afford. Alan From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:55:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:55:33 -0800 (PST) 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 g9TJtVuR022070 for ; Tue, 29 Oct 2002 11:55:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 684AC1EE8D6; Tue, 29 Oct 2002 11:56:06 -0800 (PST) Date: Tue, 29 Oct 2002 11:56:06 -0800 From: Chris Wedgwood To: "GIFFORD, ALAN (JSC-SF1) (JEC)" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Can't get my xfs partition to mount Message-ID: <20021029195606.GB5708@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: 1365 X-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 29, 2002 at 01:46:56PM -0600, GIFFORD, ALAN (JSC-SF1) (JEC) wrote: > mount returns that xfs is not supported by the kernel. Did you compile XFS into the kernel or as a module? What does /proc/filesystems say? --cw From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:57:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:57:02 -0800 (PST) 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 g9TJv0uR022249 for ; Tue, 29 Oct 2002 11:57:00 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 567F11EE8D7; Tue, 29 Oct 2002 11:57:35 -0800 (PST) Date: Tue, 29 Oct 2002 11:57:35 -0800 From: Chris Wedgwood To: yoros@wanadoo.es Cc: linux-xfs Subject: Re: Little questions Message-ID: <20021029195735.GC5708@tapu.f00f.org> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> <20021028225113.GA12476@morpheus.matrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021028225113.GA12476@morpheus.matrix.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1366 X-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 28, 2002 at 11:51:13PM +0100, yoros@wanadoo.es wrote: > Yes, I know that the files I'm deleting has a lot of extents but I > also know that other filesystems are faster deleting files. It really depends. For large files, XFS is *much* faster than anythiny else presently available for Linux. From owner-linux-xfs@oss.sgi.com Tue Oct 29 11:59:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 11:59:49 -0800 (PST) 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 g9TJxkuR022940 for ; Tue, 29 Oct 2002 11:59:46 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA04387; Tue, 29 Oct 2002 14:00:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA76421; Tue, 29 Oct 2002 14:00:14 -0600 (CST) Date: Tue, 29 Oct 2002 13:54:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "GIFFORD, ALAN (JSC-SF1) (JEC)" cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Can't get my xfs partition to mount In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1367 X-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 Alan - There are a few caveats on using Irix disks, I think there is a list in the faq, for starters. If "mount" says that xfs is not supported, can you check to see whether you got any system messages? If you compiled in xfs, check that xfs is in /proc/filesystems If xfs is a module, check that the module is loading correctly, and it should also show up in /proc/filesystems. That might be the place to start.. -Eric On Tue, 29 Oct 2002, GIFFORD, ALAN (JSC-SF1) (JEC) wrote: > I have an externel SCSI hard drive that I'd like to mount under Linux. I'm > using kernel 2.4.19, and I have > > File systems --> Partition types --> SGI partition support > > compiled into the kernel, yet when I try to mount like this: > > mount -t xfs /dev/sdb1 /mnt/sdb/ > > mount returns that xfs is not supported by the kernel. Unless the kernel > make screwed up, this has got to be wrong, because all the other stuff I > compiled into the kernel works. It's not even an option to compile it as a > module, so that can't be the problem. > > I did an fdisk /dev/sdb and looked at the partition table. It has three > partitions listed, everything looks fine, it has an SGI xfs, SGI volhdr and > SGI volume partitions listed. This drive worked on the O2 I just took it > off of, so I don't see what the problem is. > > Thanks in advance for any help you can afford. > > Alan > > From owner-linux-xfs@oss.sgi.com Tue Oct 29 12:09:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 12:09:07 -0800 (PST) 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 g9TK93uR023473 for ; Tue, 29 Oct 2002 12:09:04 -0800 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 g9TK9WXv005806; Tue, 29 Oct 2002 21:09:33 +0100 (CET) Message-Id: <4.3.2.7.2.20021029210403.03c19128@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Oct 2002 21:07:47 +0100 To: "GIFFORD, ALAN (JSC-SF1) (JEC)" , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: Can't get my xfs partition to mount In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1368 X-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:46 29-10-2002 -0600, GIFFORD, ALAN (JSC-SF1) (JEC) wrote: >I have an externel SCSI hard drive that I'd like to mount under Linux. I'm >using kernel 2.4.19, and I have Which kernel are you using? CVS, snapshot patches? > File systems --> Partition types --> SGI partition support This is SGI partition label support. That just makes it possible to look at the different partitions. It has nothing to do with XFS filesystem support. Under File systems there should be a SGI XFS filesystem option. You can use the snapshot patches from the ftp site or the CVS tree if that's easier for you. >compiled into the kernel, yet when I try to mount like this: > > mount -t xfs /dev/sdb1 /mnt/sdb/ > >mount returns that xfs is not supported by the kernel. Then: a) You did not compile it into the kernel b) The tree doesn't have XFS support. (the fs/xfs directory). Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Oct 29 12:10:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 12:10:44 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TKAguR023569 for ; Tue, 29 Oct 2002 12:10:42 -0800 Received: (qmail 22338 invoked by uid 500); 29 Oct 2002 20:10:44 -0000 Subject: Re: XFS Logs on Another Device From: Austin Gonyou To: Bernhard Erdmann Cc: Eric Sandeen , David Lloyd , linux-xfs@oss.sgi.com In-Reply-To: <3DBEE3E7.7090402@berdmann.de> References: <3DBEE3E7.7090402@berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 29 Oct 2002 14:10:44 -0600 Message-Id: <1035922244.168.19.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1369 X-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 Tue, 2002-10-29 at 13:39, Bernhard Erdmann wrote: > > Yes, the external log needs it's own partition, on any disk. I > suppose > > a whole disk might work, but that would be a horrible waste of space. > :) > > LVM is very cool for things like this. Just define a 8-12 MB Logical > Volume on another disk (Physical Volume) and use it for the log device. > Unless you're using Qlogic fibre cards!!!(qla2300 seems to be the problem child) Austin From owner-linux-xfs@oss.sgi.com Tue Oct 29 13:31:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 13:31:48 -0800 (PST) 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 g9TLVguR025012 for ; Tue, 29 Oct 2002 13:31:42 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA32827 for ; Tue, 29 Oct 2002 15:32:11 -0600 (CST) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA71230 for ; Tue, 29 Oct 2002 15:32:10 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g9U4l4B24064 for linux-xfs@oss.sgi.com; Tue, 29 Oct 2002 23:47:04 -0500 Resent-Message-Id: <200210300447.g9U4l4B24064@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA59288 for ; Tue, 29 Oct 2002 15:30:08 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g9U4j1P24054 for hch@sgi.com; Tue, 29 Oct 2002 23:45:01 -0500 Date: Tue, 29 Oct 2002 23:45:01 -0500 From: Christoph Hellwig Message-Id: <200210300445.g9U4j1P24054@dhcp212.munich.sgi.com> Subject: TAKE - more dead code removal Resent-From: hch@sgi.com Resent-Date: Tue, 29 Oct 2002 23:47:04 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1370 X-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@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Oct 29 13:29:24 PST 2002 Workarea: dhcp212.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:131386a linux/fs/xfs/xfs_vfsops.c - 1.395 - remove getting the linux inode from xfs_vget From owner-linux-xfs@oss.sgi.com Tue Oct 29 14:25:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 14:25:16 -0800 (PST) Received: from morpheus.matrix.com (193-153-180-247.uc.nombres.ttd.es [193.153.180.247]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TMP9uR025835 for ; Tue, 29 Oct 2002 14:25:10 -0800 Received: (qmail 18758 invoked by uid 1000); 29 Oct 2002 22:26:57 -0000 From: yoros@wanadoo.es Date: Tue, 29 Oct 2002 23:26:57 +0100 To: linux-xfs Subject: Re: Here is the results of my last question... Message-ID: <20021029222657.GA18631@morpheus.matrix.com> References: <20021025181514.GA21940@morpheus.matrix.com> <20021029194120.GA5708@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20021029194120.GA5708@tapu.f00f.org> User-Agent: Mutt/1.4i X-archive-position: 1371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --FCuugMFkClbJLl1L Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2002 at 11:41:20AM -0800, Chris Wedgwood wrote: > On Fri, Oct 25, 2002 at 08:15:14PM +0200, yoros@wanadoo.es wrote: >=20 > > I have experienced that using one downloader assistant (that creates > > a big sparse file an then fill it to complete download), I get a > > file with lots of extents sized from 24 to 80 blocks... Yes, I must > > run xfs_fsr after download, but it is interesant to include this > > performance to the core code... >=20 > What is this 'download assistant' --- where can I get this to test > with? I have tested downloading a lot of wgets running together in one host and the worth results came from mlDonkey downloader (eDonkey, napster, etc.. client). You can download it from http://www.freesoftware.fsf.org/mldonkey You have to compile if you are using libc6 > 2.2.x (aka 2.3.x). See you, Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9vwsxWIvihXTx06wRAkJjAKCMzvZ7YKTsCuBynaVBFqkD7oX2KwCePnUL vXhqeTcmsrmZxhtnqcYSvkE= =QHkj -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-linux-xfs@oss.sgi.com Tue Oct 29 14:28:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 14:28:35 -0800 (PST) Received: from morpheus.matrix.com (193-153-180-247.uc.nombres.ttd.es [193.153.180.247]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TMSQuR026297 for ; Tue, 29 Oct 2002 14:28:30 -0800 Received: (qmail 18806 invoked by uid 1000); 29 Oct 2002 22:30:18 -0000 From: yoros@wanadoo.es Date: Tue, 29 Oct 2002 23:30:18 +0100 To: linux-xfs Subject: Re: Little questions Message-ID: <20021029223018.GB18631@morpheus.matrix.com> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> <20021028225113.GA12476@morpheus.matrix.com> <20021029195735.GC5708@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20021029195735.GC5708@tapu.f00f.org> User-Agent: Mutt/1.4i X-archive-position: 1372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2002 at 11:57:35AM -0800, Chris Wedgwood wrote: > On Mon, Oct 28, 2002 at 11:51:13PM +0100, yoros@wanadoo.es wrote: >=20 > > Yes, I know that the files I'm deleting has a lot of extents but I > > also know that other filesystems are faster deleting files. >=20 > It really depends. For large files, XFS is *much* faster than > anythiny else presently available for Linux. When a file is very fragmented... ext2 only have to remove a few blocks (inode, simple-indirect, double-indirect, etc...). This is the historic Tanembaum's standard and a lot of UNIX-filesystems implemented this methods in the past. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9vwv6WIvihXTx06wRAlvaAJ9rBhI92mYs88BMvnJ/y7ZhNQeSdQCeNk6W ft4YmaODbFltk6+XSKmBeHE= =yZeI -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-linux-xfs@oss.sgi.com Tue Oct 29 15:08:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 15:08:04 -0800 (PST) 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 g9TN81uR027132 for ; Tue, 29 Oct 2002 15:08:01 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA73717; Tue, 29 Oct 2002 17:08:31 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-17.corp.sgi.com [134.15.64.17]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA86611; Tue, 29 Oct 2002 17:08:27 -0600 (CST) Subject: Re: Little questions From: Stephen Lord To: yoros@wanadoo.es Cc: linux-xfs In-Reply-To: <20021029223018.GB18631@morpheus.matrix.com> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> <20021028225113.GA12476@morpheus.matrix.com> <20021029195735.GC5708@tapu.f00f.org> <20021029223018.GB18631@morpheus.matrix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 29 Oct 2002 17:03:53 -0600 Message-Id: <1035932635.1088.43.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1373 X-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-29 at 16:30, yoros@wanadoo.es wrote: > On Tue, Oct 29, 2002 at 11:57:35AM -0800, Chris Wedgwood wrote: > > On Mon, Oct 28, 2002 at 11:51:13PM +0100, yoros@wanadoo.es wrote: > > > > > Yes, I know that the files I'm deleting has a lot of extents but I > > > also know that other filesystems are faster deleting files. > > > > It really depends. For large files, XFS is *much* faster than > > anythiny else presently available for Linux. > > When a file is very fragmented... ext2 only have to remove a few blocks > (inode, simple-indirect, double-indirect, etc...). This is the historic > Tanembaum's standard and a lot of UNIX-filesystems implemented this > methods in the past. > for every block in the file ext2 needs to free this block and place it in the bitmaps. For xfs the same is true, it needs to free each extent. One of the issues with a journalled filesystem is we need to keep the filesystem consistent between each transaction. The amount of work in removing a file is unbounded, and a transaction needs to have a bounded size (don't ask it gets really complicated). But what it means is that removing a file takes multiple transactions, and those end up causing disk I/O. In the case of ext2, if you crash between the remove and all the metadata getting flushed out to disk, you need to run fsck. In a journaled filesystem you do not. You are seeing one of the costs of a journaled filesystem. Steve p.s. now we wait for Stephen Tweedie to jump in with some brain wave about how to make it cheap. From owner-linux-xfs@oss.sgi.com Tue Oct 29 16:30:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 16:30:37 -0800 (PST) Received: from banna (fb171198.ot.FreeBit.NE.JP [61.203.171.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U0TDuR028664 for ; Tue, 29 Oct 2002 16:30:18 -0800 Received: from ws1ifxrj2z4yhav ([192.168.0.2]) by banna (8.9.3+3.2W/3.7W) with SMTP id JAA06350; Wed, 30 Oct 2002 09:28:21 +0900 Message-Id: <200210300028.JAA06350@banna> From: =?iso-2022-jp?B?a21haWw3NzdqcEB5YWhvby5jby5qcA==?=@banna.sgi.com To: =?iso-2022-jp?B?bWFpbDEy?=@banna.sgi.com Reply-To: kmail777@yahoo.co.jp Date: Wed, 30 Oct 2002 09:27:18 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXA8UhsoSg==?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: =?iso-2022-jp?B?a21haWw3NzdqcEB5YWhvby5jby5qcA==?=@banna.sgi.com Precedence: bulk X-list: linux-xfs <憲怣幰> 揹巕儊乕儖峀崘幮 崱屻丄峀崘傪偛婓朷偟側偄曽偼偙偙傊 (昁偢杮暥偵偁側偨偺儊乕儖傾僪儗僗偺傒傪偍彂偒壓偝偄乯 zbn30628@oak.zero.ad.jp 儊乕儖傾僪儗僗傪偛婰擖偟偰偔偩偝偄丅 仹104-0061 搶嫗搒拞墰嬫嬧嵗8-19-3 戞2僂僀儞僌價儖丂3F 儊乕儖儅僈僕儞敪峴 TEL丂03-3544-6222 FAX丂03-3544-6218 =============================================================== 栤戣彜昳偽偐傝廤傔傑偟偨偺偱丄徚偝傟傞嫲傟偑偁傝傑偡偺偱 偍怽崬傒偼偍憗傔偵両 =============================================================== 仭丂夛堳惂儘儕乕僞僋儔僽丂仭 俢倁俢丒價僨僆2500墌偐傜 僴僀僋僆儕僥傿夋幙偱偺斕攧儅僯傾僢僋側塮憸偺悢乆 傑偢偼僇僞儘僌惪媮偍懸偪偟偰偍傝傑偡乮嬊棷傔偱偺惪媮壜擻乯 偍庤尦偵偍撏偔晻摏偵偼丄偍媞條偺偍柤慜偺傒両摉幮柤偼堦愗擖傝傑偣傫丅 僇僞儘僌傪偍尒偰丄偍怽偟崬傒偔偩偝偄丅 柍椏僇僞儘僌 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂夛堳惂儘儕乕僞僋儔僽 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭SEX僼儗儞僪曞廤仭 恀寱偵SEX僼儗儞僪傪扵偟偰偄傞恖偩偗廤崌両 慡崙偳偙偱傕嬤偔偺恖傪僾儘僼傿乕儖晅偱偡偖徯夘丅 庒偄恖偐傜弉擭傑偱偄偭傁偄偄傞傛! 僟儞僫偵撪弿偺H傪妝偟傕偆両 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 儗儌儞僋儔僽 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭傕傕偑偼偠偗偰傇偳偆偑備傟傞仭 偟偠傒偲傕傕偺僐儔儃儗乕僔儑儞 儘儕乕僞價僨僆乮俢倁俢乯愱栧 偄偮傑偱塩嬈偱偒傞偐傢偐傝傑偣傫 偛拲暥偼偍憗傔偵両 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 嶌昳椺 彮彈揱愢丂柤屆壆抍抧9丂彮彈偺摴憪 側偳側偳132嶌昳丅岲昡敪攧拞両 丂(^-^)/~儘儕楩棙儉僩乕 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭丂俽俵僷乕僩僫乕徯夘懄擔丂仭 俽俵僷乕僩僫乕懄擔徯夘丅 墖彆傗SM僋儔僽偲偼堘偄丄俽俵垽岲幰偩偗偑廤偆夛丅 慡崙偱偛徯夘偱偒傑偡丅 偁側偨偺僾儗僀偵偁傢偣偰懄擔徯夘丅 僾儗僀戙嬥偼堦愗偐偐傝傑偣傫丅 擭楊偼20嵨埲忋丅 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂俽俵僋儔僽 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂恖宍巘偑嶌偭偨寙嶌昳丂仭 書偒偟傔偨偔側傞傛偆側偍恖宍偝傫偑嶌傟傑偟偨丅 敋敪揑戝僸僢僩彜昳両 悢偵惂尷偑偁傞偨傔丄偍怽偟崬傒偼偍憗傔偵両 仚嬊晹傑偱杮暔偦偭偔傝偵惂嶌偟偨偨傔丄揦摢斕攧偱偒傑偣傫丅 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂恖宍巘媨愳僨僓僀儞 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂媡墖彆岎嵺偔傜傇丂仭 慺揋側抝惈偲挬傑偱擇恖丒丒丒丅 慺揋側抝惈傪崱偡偖婱彈偺尦傊岦偐傢偣傑偡丅 慡崙僱僢僩儚乕僋偱偡偖偵徯夘俷俲丅 庒偄彈惈傕墦椂偟側偄偱梀傃傑偔傠偆両 侾夞尷傝丄挿婜丄壗偱傕偁傝丅 侓彈惈偵桪偟偔偱偒傞抝惈僗僞僢僼傕摨帪曞廤拞侓 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂媡墖彆夛 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂儅儕僼傽僫偺庬丂仭 儅儕僼傽僫偑偨傑傜側偔岲偒側恖丄偳偆偧丄偙偙傊丅 偁傇側偄偔偡傝偺忣曬傕庤偵擖傞傛両 乽愨懳偵埆梡偟側偄偱偔偩偝偄丅乿 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂怷丂惓抝 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂怴憰奐揦両寖埨僙乕儖丂仭 AV.DVD寖埨僙乕儖 懠揦偱偼庤偵擖傜側偄傕偺偽偐偟ゥゥゥ 埲慜偺傛偆偵丄傛傠偟偔偍婅偄偟傑偡丅 懠揦偵晧偗偢寖埨椏嬥両 http://www25.brinkster.com/denshimail/ http://amateur.elitecities.com/marimari/丂丂丂丂丂丂丂 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂旤彮彈僋儔僽 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 From owner-linux-xfs@oss.sgi.com Tue Oct 29 16:35:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 16:35:51 -0800 (PST) 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 g9U0ZmuR029122 for ; Tue, 29 Oct 2002 16:35:48 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA94367 for ; Tue, 29 Oct 2002 18:36:18 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA81649 for ; Tue, 29 Oct 2002 18:36:18 -0600 (CST) Received: from rose.americas.sgi.com (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9U0b4kq021052 for ; Tue, 29 Oct 2002 18:37:04 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.5/8.12.5/Submit) id g9U0b3Qj021050 for linux-xfs@oss.sgi.com; Tue, 29 Oct 2002 18:37:03 -0600 Date: Tue, 29 Oct 2002 18:37:03 -0600 From: Rusell Cattelan Message-Id: <200210300037.g9U0b3Qj021050@rose.americas.sgi.com> Subject: TAKE - Fix fsx corruption. X-archive-position: 1375 X-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@rose.americas.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Oct 29 16:32:36 PST 2002 Workarea: rose.americas.sgi.com:/usr/src/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131438a linux/fs/xfs/linux/xfs_aops.c - 1.11 - fsx (file system exerciser orginally from NeXT) does all sorts of combinations of buffered reads/write map read/writes and truncates This was exposing a problem in our write_page logic on file systems with block size < page size. From owner-linux-xfs@oss.sgi.com Tue Oct 29 16:43:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 16:43:10 -0800 (PST) Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U0h6uR029610 for ; Tue, 29 Oct 2002 16:43:06 -0800 Received: from splentec.com ([24.43.238.181]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021030004304.BOFE4298.fep04-mail.bloor.is.net.cable.rogers.com@splentec.com>; Tue, 29 Oct 2002 19:43:04 -0500 Message-ID: <3DBF2B37.3440673D@splentec.com> Date: Tue, 29 Oct 2002 19:43:35 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: linux-xfs Subject: Re: [PATCH] page_buf stuff References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.43.238.181] using ID at Tue, 29 Oct 2002 19:43:04 -0500 X-archive-position: 1376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: > > On Tue, 2002-10-29 at 01:30, Luben Tuikov wrote: > > Maybe like this? > > > > --- linux/fs/xfs/pagebuf/page_buf.c.orig Tue Oct 29 01:48:57 2002 > > +++ linux/fs/xfs/pagebuf/page_buf.c Tue Oct 29 01:52:17 2002 > > @@ -1665,22 +1665,18 @@ > > bh = bufferlist[i]; > > > > /* Complete the buffer_head, then submit the IO */ > > - if (psync) { > > - init_buffer(bh, callback, psync); > > - } else { > > - init_buffer(bh, callback, pb); > > - } > > + init_buffer(bh, callback, psync ? : pb); > > > > Well that's a little cryptic, a conditional > expression which I have to deduce is defaulting > to the left hand side in the case where there is > no right hand side. a ? a : b; <==> a ? : b; > > > bh->b_rdev = bh->b_dev; > > bh->b_rsector = bh->b_blocknr; > > set_bit(BH_Mapped, &bh->b_state); > > set_bit(BH_Req, &bh->b_state); > > - > > - if (rw == WRITE) { > > - set_bit(BH_Uptodate, &bh->b_state); > > - } > > - generic_make_request(rw, bh); > > + if (rw == WRITE) > > + set_bit(BH_Dirty, &bh->b_state); > > In general callers of the block layer > clear the dirty bit on buffers they submit, > see __block_write_full_page. In reality, > since we use generic_make_request it does > not appear these flags matter. I consider the md code to be a correct implementation. Please see the code which I refered to in the original message. If the buffer should be written out, the dirty bit should be turned on. This makes sense anywhich way you look at it and think about it. This makes sense from 1. the code I've seen in the kernel (md) and from 2. logical point of view and from 3. my old OS course textbook (``the dinosaur book''). Regarding BH_Uptodate: as you can see in the rest of the kernel, this bit is toggled when io is completed, from the callback function. Thus, it would make sense to turn it off, until the io has completed and then let the callback function set it to the proper value. IOW, I want to ensure that any stacking driver, would get the proper idea if they _were_ to check BH_Uptodate and BH_Dirty. I don't want to be getting no IO just because someone decided to check BH_Uptodate or BH_Dirty and returned the bh without actual IO. That is, I want to cover the contingencies. That is, I'm talking from a principle point of view. Please try to understand this the right way. > > } > > + for (i = 0; i < cnt; i++) > > + generic_make_request(rw, bufferlist[i]); > > On the one hand you are doing fancy optimizations > of the init_buffer call, and on the other you add > a new loop - which is not needed once the other > synchronization calls are in. This isn't ``fancy optimizations'', it's just an idiom of code of submitting bh's to generic_make_request(). You can see this done elsewhere in the kernel and is the proper way of doing it. Had the original author just used that idiom, the above for() loop could've stayed the same without the patch from Asano... Just as sticking to K&R2 C layout (Documentation/CodingStyle), I'd argue that there are certain programming idioms of the Linux kernel which are *good* to be abided by (in the kernel). Please try to understand that I'm talking out of principle here, _and_ good practice. All I want is XFS to work and be faster. We use it so I do care. This is all similar to the locking example I gave in an email of mine here some time ago, and is also similar to the if() example I also gave here found in the function we are talking about. It's all about a clear logical concept implemented in C. Clear code portrays clear logical foundation and well thought out plan. Declaring a struct in the middle of the source file is not my idea of good programming practice. pagesync_t can be part of pb -- ``locking'' is implicit in pb, and ``remain'' can be part of pb, in fact they both can be made into one by setting locking = remain + 1 (atomically of course). I've done similar things in my ``sbs'', thus the discourse. > > + run_task_queue(&tq_disk); > > ^^^^^^^^^ > > This makes XFS more synchronous in terms of disk I/O > than it needs to be. Try feeding this code a large > dbench load or something similar. Yes, I'd like that very much. Please tell me/point to the way _you_ guys do your testing. We'd like to try it here, other than our tests. > I think the only part of this which makes a difference to the > execution of the code is the run_task_queue, please explain why > it is in there. This is by clear example to the locking code I gave some emails ago. So for the same principle I'd like to see a *well defined* (one) place for run_task_queue(&tq_disk), rather than see the call all over the place. I know and realize that this may be hard as some IO is done in process context (the process which initiated it), but a kernel thread *should* do it, for sake of the comment above __get_request_wait() in ll_rw_blk.c. So when in process context, let the kernel do IO throttling, i.e. don't try and be smarter than the kernel, but when xfs's thread is doing it, running the disk task queue is essential for performance (similar thing I have in sbs). So, as you can see this was my attempt at getting closer to this model. > This means xfs has no way to coalesce any > metadata I/O beyond an individual page into the device queue. > So our 32K log writes become 8 seperate disk I/Os for starters. > Now, if you are sitting on top of lvm it is probably slicing > and dicing under the covers and masking this, if you try a > single disk I think you will notice a performance drop. Right. In which case that clear separation model as outlined above is necessary if not a MUST. That is, let's not try to out-smart the kernel. It knows best and we should do the minimal which is requred by us (on our side). This also protects us from changes elsewhere in the kernel. -- Luben P.S. I couldn't see the justifications used in XFS to treat md and lvm differently. The block layer certainly doesn't, they're just another stacking driver... From owner-linux-xfs@oss.sgi.com Tue Oct 29 16:56:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 16:56:04 -0800 (PST) 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 g9U0u1uR030090 for ; Tue, 29 Oct 2002 16:56:02 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186h9t-0002bU-00; Wed, 30 Oct 2002 00:56:33 +0000 Date: Wed, 30 Oct 2002 00:56:32 +0000 From: Christoph Hellwig To: Luben Tuikov Cc: Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff Message-ID: <20021030005632.A9930@infradead.org> References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.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: <3DBF2B37.3440673D@splentec.com>; from luben@splentec.com on Tue, Oct 29, 2002 at 07:43:35PM -0500 X-archive-position: 1377 X-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 Tue, Oct 29, 2002 at 07:43:35PM -0500, Luben Tuikov wrote: > a ? a : b; <==> a ? : b; It's a non-standard extension, and IMHO not a very good idea. If your expression is long enough that you'd need it you should be using explicit if-statements anyway. > I consider the md code to be a correct implementation. Please > see the code which I refered to in the original message. The 2.4 MD code isn't exactly a good reference to copy from :) 2.5 md code is a lot better, but that one deals only with bios, not buffer_heads. > If the buffer should be written out, the dirty bit should be turned on. > This makes sense anywhich way you look at it and think about it. > This makes sense from 1. the code I've seen in the kernel (md) > and from 2. logical point of view and from 3. my old OS course textbook > (``the dinosaur book''). It makes sense if you let the VM control the write out, but pagebuf does the writeout explicit and the bit doesn't matter at all. > Regarding BH_Uptodate: as you can see in the rest of the kernel, > this bit is toggled when io is completed, from the callback function. > Thus, it would make sense to turn it off, until the io has > completed and then let the callback function set it to the proper value. Look at fs/buffer.c - usually we set it before submitting and clear it if the I/O failed. And yes, this is confusing when you look at it. > IOW, I want to ensure that any stacking driver, would get the proper > idea if they _were_ to check BH_Uptodate and BH_Dirty. I don't want to > be getting no IO just because someone decided to check BH_Uptodate > or BH_Dirty and returned the bh without actual IO. That is, I want to > cover the contingencies. Drivers should never ever look at BH_Dirty. Forstunately the I/O containers and buffer_heads are completly separate in 2.5 to avoid such mess. > Yes, I'd like that very much. Please tell me/point to the way _you_ > guys do your testing. We'd like to try it here, other than our tests. the xfs CVS repo has a cmd/xfstest subdir, that's the XFS-specific test suite, we also run the linuxtestproject (ltp) and many of the tools from Andrew Mortons ext3 suite (see sf.net/projects/gkernel/) over it. From owner-linux-xfs@oss.sgi.com Tue Oct 29 19:49:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 19:49:05 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U3n1uR016695 for ; Tue, 29 Oct 2002 19:49:01 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id TAA27447 for ; Tue, 29 Oct 2002 19:49:31 -0800 (PST) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002102919510922058 ; Tue, 29 Oct 2002 19:51:09 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 19:49:32 -0800 Received: from digeo.com ([172.17.144.18]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Oct 2002 19:49:29 -0800 Message-ID: <3DBF56C9.B09ED205@digeo.com> Date: Tue, 29 Oct 2002 19:49:29 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.42 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rusell Cattelan , linux-xfs Subject: Re: TAKE - Fix fsx corruption. References: <200210300037.g9U0b3Qj021050@rose.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2002 03:49:29.0757 (UTC) FILETIME=[598F2CD0:01C27FC7] X-archive-position: 1378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Rusell Cattelan wrote: > > - fsx (file system exerciser orginally from NeXT) > does all sorts of combinations of buffered reads/write map read/writes and truncates > This was exposing a problem in our write_page logic on file systems with block size < page size. fsx-linux is great. It caused me *no end* of grief in 2.5.13 ;) I have a warmed-up version which does O_DIRECT testing as well. Just give it the `-Z' flag to force O_DIRECT access and the existing `-r' and `-w' flags to set the alignments and `-R' and `-W' to supress mmap access. (I don't think testing mmap and O_DIRECT consistency at the same time is an interesting thing to do. But, to my surprise, it _does_ work). So to test the fancy finer-than-blocksize direct-IO support which Linus just merged, use: fsx-linux -r 1024 -w 512 -R -W -Z foo Grab it from http://www.zip.com.au/~akpm/linux/patches/stuff/ From owner-linux-xfs@oss.sgi.com Tue Oct 29 19:52:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 19:52:43 -0800 (PST) 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 g9U3qfuR017098 for ; Tue, 29 Oct 2002 19:52:41 -0800 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 TAA03462 for ; Tue, 29 Oct 2002 19:53:16 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA48682 for linux-xfs@oss.sgi.com; Wed, 30 Oct 2002 14:51:58 +1100 (EST) Date: Wed, 30 Oct 2002 14:51:58 +1100 (EST) From: Nathan Scott Message-Id: <200210300351.OAA48682@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - block device error handling fixes X-archive-position: 1379 X-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 a couple of issues on the error path when dealing with external devices (log/realtime). path_init was missing the LOOKUP_POSITIVE flag, so it would fail to tell us if the file doesn't exist; there was a spot where we were returning a wrongly signed error code; and when mount is failing, we can call into xfs_blkdev_put with a NULL pointer depending on which devices were initialised and which weren't. You wouldn't normally hit this, but a typo in your mount options (like I had ;) along the lines "-o logdev=4" would cause a panic. Date: Tue Oct 29 19:47:25 PST 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:131469a linux/fs/xfs/linux/xfs_super.c - 1.224 From owner-linux-xfs@oss.sgi.com Tue Oct 29 22:37:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 22:37:14 -0800 (PST) Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U6bAuR021863 for ; Tue, 29 Oct 2002 22:37:12 -0800 Received: from splentec.com ([24.43.238.181]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021030063640.XQPV4286.fep03-mail.bloor.is.net.cable.rogers.com@splentec.com>; Wed, 30 Oct 2002 01:36:40 -0500 Message-ID: <3DBF7E2F.57C503D@splentec.com> Date: Wed, 30 Oct 2002 01:37:35 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.com> <20021030005632.A9930@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.43.238.181] using ID at Wed, 30 Oct 2002 01:36:40 -0500 X-archive-position: 1380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Tue, Oct 29, 2002 at 07:43:35PM -0500, Luben Tuikov wrote: > > a ? a : b; <==> a ? : b; > > It's a non-standard extension, and IMHO not a very good idea. > If your expression is long enough that you'd need it you > should be using explicit if-statements anyway. I, OTOH, do NOT have any particular problems with *new* things. You see it once, you see it twice and eventually get used to it and use it yourself. (Like struct list_head, which I really love!) I do think that it's a good idea. Do you really like this: if (psync) { init_buffer(bh, callback, psync); } else { init_buffer(bh, callback, pb); } over this: init_buffer(bh, callback, psync ? : pb); Really? You like the first better? My patch will *never* make it to the xfs source so why do you care? It was just an example. Next time I'll know and save 1/2 hour of my precious time on this planet. > > I consider the md code to be a correct implementation. Please > > see the code which I refered to in the original message. > > The 2.4 MD code isn't exactly a good reference to copy from :) > 2.5 md code is a lot better, but that one deals only with bios, > not buffer_heads. As you have probably deduced, we're using the 2.4 series (stable release) kernel. If you haven't deduced this: we are using the 2.4 series (stable release) kernel. > > If the buffer should be written out, the dirty bit should be turned on. > > This makes sense anywhich way you look at it and think about it. > > This makes sense from 1. the code I've seen in the kernel (md) > > and from 2. logical point of view and from 3. my old OS course textbook > > (``the dinosaur book''). > > It makes sense if you let the VM control the write out, but pagebuf > does the writeout explicit and the bit doesn't matter at all. So, you do admit that ``it makes sense ...'' -- so you agree with me. (My god -- did you?! You'll now be ousted from linux-xfs!) So, IOW, this would be *consistent* with the rest (VM, you mention). So, let's be consistent. Let's turn on the dirty bit. This will be consistent as if coming from the VM, you say... so the LL driver wouldn't be playing guessing games where the thing came from... So let's just be consistent. > Look at fs/buffer.c - usually we set it before submitting and clear > it if the I/O failed. And yes, this is confusing when you look > at it. Why are you repeating what I'm saying? You alrealy admit that it is confusing so what is the value and purpose of your post here? Why not just admit that this is the reversed logic, and have the io completion callback worry about the Uptodate bit. Logically Uptodate is false, before the buffer has been written out to the media (for WRITE operations). And I try to only do things which *make sense*. Think about it: if the buffer was never written to the media, but traveled to the lower driver: Uptodate=false (set by the callback), now what is the difference wrt to the buffer if it didn't travel to the lower driver? Uptodate should be set to false, Dirty to true, then submit -- makes sense? > Drivers should never ever look at BH_Dirty. (Can you guarantee that no such (stacking) drivers exist?) I see md does it, implicitly by turning it on -- I guess it's just being consistent. Rather than nit-picking on my emails, why don't you just tell me what would MAKE SENSE? Would it *make sense* to turn on BH_Dirty before submitting to the lower driver? You could've easily said: Yes, it makes sense to turn it on before submitting a bh for write. > Forstunately the I/O > containers and buffer_heads are completly separate in 2.5 to avoid > such mess. I repeat again: we're using 2.4.x. I also know about 2.5, bios, blah, blah, but this is COMPLETELY IRRELEVANT, has no value here/now, and would not help us AT ALL until we start using 2.5. Why are you mentioning 2.5 at all? I cannot possibly believe (by your attitude towards my posts here) that you think any improvement in xfs is due. All I've seen is you nit-picking on my posts. Why don't you comment on the other things I posted: (which I consider to be the real issues) - the pg locking clearly pulled in one place, - coalescing pagesync_t into pg with a single atomic var, - the if goto fiasco, - having extra code with one purpose: debugging, (not talking about BUG()) removed. - a centralized generic_make_request() calling scheme, rather than all over the place, - etc... This would make sense and help xfs improve, not nit-picking short conditionals. Good luck guys, -- Luben From owner-linux-xfs@oss.sgi.com Tue Oct 29 22:55:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Oct 2002 22:55:55 -0800 (PST) Received: from morpheus.matrix.com (193-153-180-247.uc.nombres.ttd.es [193.153.180.247]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U6tmuR022737 for ; Tue, 29 Oct 2002 22:55:49 -0800 Received: (qmail 20711 invoked by uid 1000); 30 Oct 2002 05:11:02 -0000 From: yoros@wanadoo.es Date: Wed, 30 Oct 2002 06:11:02 +0100 To: linux-xfs Subject: Re: Little questions Message-ID: <20021030051102.GA20670@morpheus.matrix.com> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> <20021028225113.GA12476@morpheus.matrix.com> <20021029195735.GC5708@tapu.f00f.org> <20021029223018.GB18631@morpheus.matrix.com> <1035932635.1088.43.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <1035932635.1088.43.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yoros@wanadoo.es Precedence: bulk X-list: linux-xfs --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2002 at 05:03:53PM -0600, Stephen Lord wrote: > On Tue, 2002-10-29 at 16:30, yoros@wanadoo.es wrote: > > On Tue, Oct 29, 2002 at 11:57:35AM -0800, Chris Wedgwood wrote: > > > On Mon, Oct 28, 2002 at 11:51:13PM +0100, yoros@wanadoo.es wrote: > > >=20 > > > > Yes, I know that the files I'm deleting has a lot of extents but I > > > > also know that other filesystems are faster deleting files. > > >=20 > > > It really depends. For large files, XFS is *much* faster than > > > anythiny else presently available for Linux. > >=20 > > When a file is very fragmented... ext2 only have to remove a few blocks > > (inode, simple-indirect, double-indirect, etc...). This is the historic > > Tanembaum's standard and a lot of UNIX-filesystems implemented this > > methods in the past. > >=20 >=20 > for every block in the file ext2 needs to free this block and place it > in the bitmaps. For xfs the same is true, it needs to free each extent. > One of the issues with a journalled filesystem is we need to keep the > filesystem consistent between each transaction. The amount of work in > removing a file is unbounded, and a transaction needs to have a bounded > size (don't ask it gets really complicated). But what it means is > that removing a file takes multiple transactions, and those end > up causing disk I/O.=20 >=20 > In the case of ext2, if you crash between the remove and all the > metadata getting flushed out to disk, you need to run fsck. In > a journaled filesystem you do not. You are seeing one of the costs > of a journaled filesystem. Yes, I understand that removing a file with more than 40000 extents takes a LOT of time and that is not bad because such file has too much extents. What structure is created for each extent? This is the quextion because updating 40000 "bits" of a bitmap (like ext2) is very quick. I only want to know what is the way to get best performance with XFS. Pedro --=20 Pedro Martinez Juli=E1 \ yoros@terra.es )| yoros@wanadoo.es / http://yoros.cjb.net Socio HispaLinux #311 Usuario Linux #275438 - http://counter.li.org GnuPG public information: pub 1024D/74F1D3AC Key fingerprint =3D 8431 7B47 D2B4 5A46 5F8E 534F 588B E285 74F1 D3AC --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9v2nmWIvihXTx06wRArC2AKCEgm9F2XKsFvxh8xMNyHFoF62TEgCgr8aA qjXrs+Pjq26W8tEfMrBErIw= =sX03 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-linux-xfs@oss.sgi.com Wed Oct 30 03:51:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 03:51:42 -0800 (PST) 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 g9UBpcuR030134 for ; Wed, 30 Oct 2002 03:51:39 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186rOM-0006LC-00; Wed, 30 Oct 2002 11:52:10 +0000 Date: Wed, 30 Oct 2002 11:52:10 +0000 From: Christoph Hellwig To: Luben Tuikov Cc: Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff Message-ID: <20021030115210.A24361@infradead.org> References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.com> <20021030005632.A9930@infradead.org> <3DBF7E2F.57C503D@splentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DBF7E2F.57C503D@splentec.com>; from luben@splentec.com on Wed, Oct 30, 2002 at 01:37:35AM -0500 X-archive-position: 1382 X-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 30, 2002 at 01:37:35AM -0500, Luben Tuikov wrote: > Do you really like this: > > if (psync) { > init_buffer(bh, callback, psync); > } else { > init_buffer(bh, callback, pb); > } > > over this: > > init_buffer(bh, callback, psync ? : pb); > > Really? You like the first better? No, I don't like both :) Just use evaluate psync twice instead of the GNU-extension: init_buffer(bh, callback, psync ? psync : pb); > > The 2.4 MD code isn't exactly a good reference to copy from :) > > 2.5 md code is a lot better, but that one deals only with bios, > > not buffer_heads. > > As you have probably deduced, we're using the 2.4 series > (stable release) kernel. > > If you haven't deduced this: we are using the 2.4 series > (stable release) kernel. Thanks Luben, I might not be a genius like you, but I can guess that you use 2.4 when you submit patches against that tree. Which still doesn't make the 2.4 md driver a good example. > > It makes sense if you let the VM control the write out, but pagebuf > > does the writeout explicit and the bit doesn't matter at all. > > So, you do admit that ``it makes sense ...'' -- so you agree with me. > (My god -- did you?! You'll now be ousted from linux-xfs!) > > So, IOW, this would be *consistent* with the rest (VM, you mention). > So, let's be consistent. Let's turn on the dirty bit. This will be > consistent as if coming from the VM, you say... so the LL driver wouldn't > be playing guessing games where the thing came from... So let's just be > consistent. No. Let me repeat: BH_dirty is an VM-internal state bit. Unless you want VM-controlled writeback of the buffer (by putting in on the LRU list) you should NOT set it. > > Look at fs/buffer.c - usually we set it before submitting and clear > > it if the I/O failed. And yes, this is confusing when you look > > at it. > > Why are you repeating what I'm saying? You alrealy admit that > it is confusing so what is the value and purpose of your post here? > > Why not just admit that this is the reversed logic, and have the > io completion callback worry about the Uptodate bit. I told you that this is the way the generic I/O path does it for a reason. The pagebuf code doesn't need it and we could discuss two days whether it's more intuitive to follow the most used and reviewed code or do what people expect from other operating systems. I don't really care personally, but I have strong feeling that changing it from whathever it was before is rather useless.. > > Drivers should never ever look at BH_Dirty. > > (Can you guarantee that no such (stacking) drivers exist?) I can guarantee you that such a driver is broken. (Note that loop.c does look at BH_Dirty, but only for buffers it submitted by itself) > COMPLETELY IRRELEVANT, has no value here/now, and would > not help us AT ALL until we start using 2.5. > > Why are you mentioning 2.5 at all? Please excuse me for mentioning a kernel you don't actually use. Please tell me the exact 2.4 patchlevel you use so that I'll never have to bother you with kernel irrelevant to you.. > Why don't you comment on the other things I posted: > (which I consider to be the real issues) > - the pg locking clearly pulled in one place, > - coalescing pagesync_t into pg with a single atomic var, > - the if goto fiasco, > - having extra code with one purpose: debugging, > (not talking about BUG()) removed. > - a centralized generic_make_request() calling scheme, > rather than all over the place, > - etc... > This would make sense and help xfs improve, not nit-picking > short conditionals. What about submitting one patch per change, with a usefull comment instead of ranting? From owner-linux-xfs@oss.sgi.com Wed Oct 30 04:08:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 04:08:18 -0800 (PST) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UC8CuR000754 for ; Wed, 30 Oct 2002 04:08:13 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g9UC8nl21894 for ; Wed, 30 Oct 2002 21:08:49 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g9UC8m807772 for ; Wed, 30 Oct 2002 21:08:48 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g9UC8m220186 for ; Wed, 30 Oct 2002 21:08:48 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA487 for ; Wed, 30 Oct 2002 21:08:36 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Oct 30 21:08:35 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g9UC8kb90834; Wed, 30 Oct 2002 21:08:47 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g9UC8kI16597; Wed, 30 Oct 2002 21:08:46 +0900 To: lord@sgi.com Cc: sandeen@sgi.com, hch@infradead.org, linux-xfs@oss.sgi.com Subject: Re: xfs_syncsub() question In-Reply-To: <1035840317.2570.512.camel@jen.americas.sgi.com> References: <1035840317.2570.512.camel@jen.americas.sgi.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Informed Management) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021030210846Q.masano@tnes.nec.co.jp> Date: Wed, 30 Oct 2002 21:08:46 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 17 X-archive-position: 1383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Hi, Thank you for comments. > On Sun, 2002-10-27 at 22:05, Eric Sandeen wrote: > > Hi, I'll have to look a bit more closely... but your patch does look correct. > > Back in 2000 (v. 1.279), it was as you suggest, but Steve changed it. > > :) Steve? > > I no longer remember the why of this change, I think we can just revert > to this code. Ok, I'm waiting someone commit the code. :) Because it seems possibly critical if it is called at umount. -- Masano From owner-linux-xfs@oss.sgi.com Wed Oct 30 05:07:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 05:07:55 -0800 (PST) Received: from jiyu.esil.univ-mrs.fr (jiyu.esil.univ-mrs.fr [139.124.44.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UD7WuR002663; Wed, 30 Oct 2002 05:07:33 -0800 Received: from localhost (localhost.esil.univ-mrs.fr [127.0.0.1]) by jiyu.esil.univ-mrs.fr (Thomson TO7 SMTP mail server) with ESMTP id 5796C24D1B; Wed, 30 Oct 2002 14:08:03 +0100 (CET) Received: from esil.univ-mrs.fr (elop3du13.esil.univ-mrs.fr [139.124.32.83]) by jiyu.esil.univ-mrs.fr (Thomson TO7 SMTP mail server) with ESMTP id 01D8A24D0E; Wed, 30 Oct 2002 14:07:57 +0100 (CET) Message-ID: <3DBFDB00.46CA43ED@esil.univ-mrs.fr> Date: Wed, 30 Oct 2002 14:13:36 +0100 From: Frederic BERTON X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 Subject: Bioinformatics Content-Type: multipart/mixed; boundary="------------CC08D6435A2FC1849BCD8E57" To: undisclosed-recipients: ; X-Virus-Scanned: by AMaViS perl-10 X-archive-position: 1384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Frederic.Berton@esil.univ-mrs.fr Precedence: bulk X-list: linux-xfs Il s'agit d'un message multivolet au format MIME. --------------CC08D6435A2FC1849BCD8E57 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Madam, Dear Sir, Recently, I have been researching the leading research centers in biotechnology in the world and the name of Silicon Graphics BioInformatics keeps coming up as a top project in the center of bioinformatics. I am currently in my last year of engineering school in biotechnology in Marseille (ESIL) and I really want to join a team such as yours. Really interested in drug design, molecular modeling and construction of softwares, I am looking for a six month training course (February-August 2002 or more) focused on bioinformatics. My training as an engineer in biotechnology taught me a solid background in cellular and molecular biology, biochemistry and biotechnological processes, construction of database, biostatistics, programming, molecular modeling, blasts. Moreover, during my assistantship in the team of Henrissat at the french National Centre of Scientific Research, I was part of a team responsible for the development of a cartographic tool for the completely sequenced microorganisms. In addition to my knowledge in laboratory technics, I have communication, bioinformatics (Lab-on-Chip) and project management skills. As well as learning from your training, I am sure that can make a valuable contribution to Silicon Graphics BioInformatics. I join you a copy of this letter and my resume. I look forward to hearing from you. Yours sincerely, Fr閐閞ic Berton -- Frederic BERTON, El鑦e ESIL D閜artement GBMA email : Frederic.BERTON@esil.univ-mrs.fr --------------CC08D6435A2FC1849BCD8E57 Content-Type: application/msword; name="cover letter Silicon Graphics BioInformatics .doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="cover letter Silicon Graphics BioInformatics .doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAJgAAAAAAAAAAEAAAKAAAAAEAAAD+////AAAAACUAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEAcQAMBAAAABK/AAAAAAAAEAAAAAAABAAA vQoAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAMBBYAHhgAABZBAQAW QQEAvQYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAABIBAAAA AAAAEgEAABIBAAAAAAAAEgEAAAAAAAASAQAAAAAAABIBAAAAAAAAEgEAABQA AAAAAAAAAAAAACYBAAAAAAAAJgEAAAAAAAAmAQAAAAAAACYBAAAAAAAAJgEA AAwAAAAyAQAAFAAAACYBAAAAAAAAiwgAALYAAABSAQAAAAAAAFIBAAAAAAAA UgEAAAAAAABSAQAAAAAAAFIBAAAAAAAAUgEAAAAAAABSAQAAAAAAAFIBAAAA AAAAUAgAAAIAAABSCAAAAAAAAFIIAAAAAAAAUggAAAAAAABSCAAAAAAAAFII AAAAAAAAUggAACQAAABBCQAA9AEAADULAABiAAAAdggAABUAAAAAAAAAAAAA AAAAAAAAAAAAEgEAAAAAAABSAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAQAA AAAAAFIBAAAAAAAAUgEAAAAAAABSAQAAAAAAAHYIAAAAAAAA+gIAAAAAAAAS AQAAAAAAABIBAAAAAAAAUgEAAAAAAAAAAAAAAAAAAFIBAAAAAAAAUgEAAAAA AAD6AgAAAAAAAPoCAAAAAAAA+gIAAAAAAABSAQAAqAEAABIBAAAAAAAAUgEA AAAAAAASAQAAAAAAAFIBAAAAAAAAUAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA JgEAAAAAAAAmAQAAAAAAABIBAAAAAAAAEgEAAAAAAAASAQAAAAAAABIBAAAA AAAAUgEAAAAAAABQCAAAAAAAAPoCAABWBQAA+gIAAAAAAAAAAAAAAAAAAFAI AAAAAAAAEgEAAAAAAAASAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAgAAAAAAABSAQAA AAAAAEYBAAAMAAAAQEtR2RSAwgEmAQAAAAAAACYBAAAAAAAA+gIAAAAAAABQ CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAT2N0b2JlciAgMzB0aCAsIDIwMDIJCQkJCQkJRnLpZOlyaWMgQkVS VE9ODTExMiBCb3VsZXZhcmQgU2FpbnRlIE1hcmd1ZXJpdGUNMTMwMDkgTWFy c2VpbGxlDUZyYW5jZQ0NDQ0NDVNpbGljb24gR3JhcGhpY3MgQmlvSW5mb3Jt YXRpY3MgDTIwMTEgTi4gU2hvcmVsaW5lIEJsdmQuIEJsZGcuIDIwTA1Nb3Vu dGFpbiBWaWV3DUNBIDk0MDQzDVVTQQ0NDQ1TdW1tYXJ5OiBIaWdobHkgbW90 aXZhdGVkIGFuZCBjb21wZXRlbnQgZmluYWwgeWVhciBlbmdpbmVlcmluZyBz dHVkZW50IHNlZWtpbmcgYSBzaXggbW9udGggdHJhaW5pbmcgcGVyaW9kDQ0N DQ0NRGVhciBNYWRhbSwgRGVhciAgU2lyLA0NDVJlY2VudGx5LCBJIGhhdmUg YmVlbiByZXNlYXJjaGluZyB0aGUgbGVhZGluZyByZXNlYXJjaCBjZW50ZXJz IGluIGJpb3RlY2hub2xvZ3kgaW4gdGhlIHdvcmxkIGFuZCB0aGUgbmFtZSBv ZiBTaWxpY29uIEdyYXBoaWNzIEJpb0luZm9ybWF0aWNzIGtlZXBzIGNvbWlu ZyB1cCBhcyBhIHRvcCBwcm9qZWN0IGluIHRoZSBjZW50ZXIgb2YgYmlvaW5m b3JtYXRpY3MuIA0NSSBhbSBjdXJyZW50bHkgaW4gbXkgbGFzdCB5ZWFyIG9m IGVuZ2luZWVyaW5nIHNjaG9vbCBpbiBiaW90ZWNobm9sb2d5IGluIE1hcnNl aWxsZSAoRVNJTCkgYW5kIEkgcmVhbGx5IHdhbnQgdG8gam9pbiBhIHRlYW0g c3VjaCBhcyB5b3Vycy4gUmVhbGx5IGludGVyZXN0ZWQgaW4gZHJ1ZyBkZXNp Z24sIG1vbGVjdWxhciBtb2RlbGluZyBhbmQgY29uc3RydWN0aW9uIG9mIHNv ZnR3YXJlcywgSSBhbSBsb29raW5nIGZvciBhIHNpeCBtb250aCB0cmFpbmlu ZyBjb3Vyc2UgKEZlYnJ1YXJ5LUF1Z3VzdCAyMDAyIG9yIG1vcmUpIGZvY3Vz ZWQgb24gYmlvaW5mb3JtYXRpY3MuDQ1NeSB0cmFpbmluZyBhcyBhbiBlbmdp bmVlciBpbiBiaW90ZWNobm9sb2d5IHRhdWdodCBtZSBhIHNvbGlkIGJhY2tn cm91bmQgaW4gY2VsbHVsYXIgYW5kIG1vbGVjdWxhciBiaW9sb2d5LCBiaW9j aGVtaXN0cnkgYW5kIGJpb3RlY2hub2xvZ2ljYWwgcHJvY2Vzc2VzLCBjb25z dHJ1Y3Rpb24gb2YgZGF0YWJhc2UsIGJpb3N0YXRpc3RpY3MsIHByb2dyYW1t aW5nLCBtb2xlY3VsYXIgbW9kZWxpbmcsIGJsYXN0cy4NTW9yZW92ZXIsIGR1 cmluZyBteSBhc3Npc3RhbnRzaGlwIGluIHRoZSB0ZWFtIG9mIEhlbnJpc3Nh dCBhdCB0aGUgZnJlbmNoIE5hdGlvbmFsIENlbnRyZSBvZiBTY2llbnRpZmlj IFJlc2VhcmNoLCBJIHdhcyBwYXJ0IG9mIGEgdGVhbSByZXNwb25zaWJsZSBm b3IgdGhlIGRldmVsb3BtZW50IG9mIGEgY2FydG9ncmFwaGljIHRvb2wgZm9y IHRoZSBjb21wbGV0ZWx5IHNlcXVlbmNlZCBtaWNyb29yZ2FuaXNtcy4NSW4g YWRkaXRpb24gdG8gbXkga25vd2xlZGdlIGluIGxhYm9yYXRvcnkgdGVjaG5p Y3MsIEkgaGF2ZSBjb21tdW5pY2F0aW9uLCBiaW9pbmZvcm1hdGljcyAoTGFi LW9uLUNoaXApIGFuZCBwcm9qZWN0IG1hbmFnZW1lbnQgc2tpbGxzLg0NDUFz IHdlbGwgYXMgbGVhcm5pbmcgZnJvbSB5b3VyIHRyYWluaW5nLCBJIGFtIHN1 cmUgdGhhdCBjYW4gbWFrZSBhIHZhbHVhYmxlIGNvbnRyaWJ1dGlvbiB0byBT aWxpY29uIEdyYXBoaWNzIEJpb0luZm9ybWF0aWNzLg1JIGpvaW4geW91IGEg Y29weSBvZiB0aGlzIGxldHRlciBhbmQgbXkgcmVzdW1lLiBJIGxvb2sgZm9y d2FyZCB0byBoZWFyaW5nIGZyb20geW91Lg0NDVlvdXJzIHNpbmNlcmVseSwN DQ1Gculk6XJpYyBCZXJ0b24NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAsEAAAOBAAAFAQAABUEAAAbBAAAKwQA AGIEAACIBAAAxAQAADMFAAC+BQAA3gUAACAKAABACgAAQQoAAJUKAAC9CgAA AP0A+wD7APsA9/QA9AD0APQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEbUgJCAAHNgiBbUgJCAM1CIEDSCoBABEABAAAKwQAAEsE AABbBAAAYgQAAGMEAABkBAAAZQQAAGYEAABnBAAAiAQAAKoEAAC4BAAAwQQA AMUEAADGBAAAxwQAAMgEAAAzBQAANAUAADUFAAA2BQAANwUAADgFAABPBQAA UAUAAFEFAAD8AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAA AAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAA AAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4A AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAA AAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAAcPAAMkAw+EAAARhP// Aw8AAyQDBQ8AAyQDEYT5/wcPAAMkAw+EAAARhPn/Bw8AAyQDD4TrGBGE+f8D AAADJAMAGgAEAAArBAAASwQAAFsEAABiBAAAYwQAAGQEAABlBAAAZgQAAGcE AACIBAAAqgQAALgEAADBBAAAxQQAAMYEAADHBAAAyAQAADMFAAA0BQAANQUA ADYFAAA3BQAAOAUAAE8FAABQBQAAUQUAACEGAAAiBgAAZwcAAGgHAABTCAAA PQkAAMMJAADECQAAxQkAAEEKAACVCgAAlgoAAJcKAACoCgAAqQoAAKoKAAC6 CgAAuwoAALwKAAC9CgAA/v7+/v7+/v7+/Pz8/Pz+/v7+/v7+/v7+/v78/v7+ /v7+/v78/v7+/v7+/v7+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAMCDwACAQEuUQUAACEGAAAiBgAAZwcAAGgHAABT CAAAPQkAAMMJAADECQAAxQkAAEEKAACVCgAAlgoAAJcKAACoCgAAqQoAAKoK AAC6CgAAuwoAALwKAAC9CgAA+AAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ8AAyQDEYT/ /wABAAADDwADJAMHDwADJAMPhAAAEYT//wcPAAMkAw+EAAARhPn/ABQcAB+w gi4gsMZBIbCJBSKwiQUjkIkFJJCJBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABIAEAAKAAEAWwAPAAIAAAAAAAAAMAAAQPH/AgAwAAwA BgBOAG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAwEc0gMBHRIDAQsAAEAAQAC ACwAAAAHAFQAaQB0AHIAZQAgADEAAAAIAAEABiQBQCYAAwA1CIEAAAAAAAAA AAAAAAAAAAAAADIAQUDy/6EAMgAMABEAUABvAGwAaQBjAGUAIABwAGEAcgAg AGQA6QBmAGEAdQB0AAAAAAAAAAAAAAAAAFAAQ0ABAPIAUAAMABYAUgBlAHQA cgBhAGkAdAAgAGMAbwByAHAAcwAgAGQAZQAgAHQAZQB4AHQAZQAAABIADwAP hLAbEYRQ5F6EsBtghFDkAAAAAAAAvQYAAA4AABgAAAcA/////wAEAAC9CgAA CAAAAAAEAABRBQAAvQoAAAkAAAALAAAAAAQAAL0KAAAKAAAAAAAAAAcAAAAJ AAAACwAAAGcAAADIAAAANQEAADUBAACIAQAAjwEAAL4BAADeAQAABgIAAAwC AAAQAgAAHgIAAGsCAAB0AgAA2AIAAOACAAD1AgAA/gIAADcDAAA9AwAAVwMA AGUDAAAbBAAAKAQAAEEEAABJBAAAhAQAAI0EAACVBAAAmwQAAC0FAAA7BQAA ZwUAAG8FAACHBQAAlQUAACAGAAA/BgAAQwYAAEcGAABIBgAASwYAAE4GAABS BgAAVgYAAFoGAABbBgAAYQYAAGYGAABoBgAAaQYAAG8GAAB4BgAAfwYAAIAG AACCBgAAgwYAAIoGAACLBgAAjwYAAJAGAACTBgAAqgYAALIGAACzBgAAuQYA AL8GAAAcAAcABAAHAAQABwAEAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcA HAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHAP//FAAAAAQARwBCAE0AQQBBAFwAXABoAG8AbQBlAHMAXABm AGIAZQByAHQAbwBuAFwAYwB2AFwAYwBvAHYAZQByACAAbABlAHQAdABlAHIA IABNAG8AbABlAGMAdQBsAGEAcgAgAE0AaQBuAGkAbgBnACAAQwBvAHIAcABv AHIAYQB0AGkAbwBuACAALgBkAG8AYwAEAEcAQgBNAEEANgBcAFwAaABvAG0A ZQBzAFwAZgBiAGUAcgB0AG8AbgBcAGMAdgBcAGMAbwB2AGUAcgAgAGwAZQB0 AHQAZQByACAATQB5AGMAbwB0AGEAIABCAGkAbwBzAGMAaQBlAG4AYwBlAHMA LgBkAG8AYwAEAEcAQgBNAEEAKgBcAFwAaABvAG0AZQBzAFwAZgBiAGUAcgB0 AG8AbgBcAGMAdgBcAGMAbwB2AGUAcgAgAGwAZQB0AHQAZQByACAATgBlAHQA LQBJAEQALgBkAG8AYwAEAEcAQgBNAEEAVgBDADoAXABEAE8AQwBVAE0ARQB+ ADEAXABmAGIAZQByAHQAbwBuAFwATABPAEMAQQBMAFMAfgAxAFwAVABlAG0A cABcAEUAbgByAGUAZwBpAHMAdAByAGUAbQBlAG4AdAAgAGEAdQB0AG8AbQBh AHQAaQBxAHUAZQAgAGQAZQBjAG8AdgBlAHIAIABsAGUAdAB0AGUAcgAgAE4A ZQB0AC0ASQBEAC4AYQBzAGQABABHAEIATQBBADIAXABcAGgAbwBtAGUAcwBc AGYAYgBlAHIAdABvAG4AXABjAHYAXABjAG8AdgBlAHIAIABsAGUAdAB0AGUA cgAgAFAAYQBuAGcAZQBhACAAUwB5AHMAdABlAG0AcwAuAGQAbwBjAAQARwBC AE0AQQAxAFwAXABoAG8AbQBlAHMAXABmAGIAZQByAHQAbwBuAFwAYwB2AFwA YwBvAHYAZQByACAAbABlAHQAdABlAHIAIABQAHIAbwB0AGUAbwBNAGUAdABy AGkAYwBzAC4AZABvAGMABABHAEIATQBBAF0AQwA6AFwARABPAEMAVQBNAEUA fgAxAFwAZgBiAGUAcgB0AG8AbgBcAEwATwBDAEEATABTAH4AMQBcAFQAZQBt AHAAXABFAG4AcgBlAGcAaQBzAHQAcgBlAG0AZQBuAHQAIABhAHUAdABvAG0A YQB0AGkAcQB1AGUAIABkAGUAYwBvAHYAZQByACAAbABlAHQAdABlAHIAIABQ AHIAbwB0AGUAbwBNAGUAdAByAGkAYwBzAC4AYQBzAGQABABHAEIATQBBADgA XABcAGgAbwBtAGUAcwBcAGYAYgBlAHIAdABvAG4AXABjAHYAXABjAG8AdgBl AHIAIABsAGUAdAB0AGUAcgAgAFIAbwBzAGUAdAB0AGEAIABJAG4AcABoAGEA cgBtAGEAdABpAGMAIAAuAGQAbwBjAAQARwBCAE0AQQA4AFwAXABoAG8AbQBl AHMAXABmAGIAZQByAHQAbwBuAFwAYwB2AFwAYwBvAHYAZQByACAAbABlAHQA dABlAHIAIABSAG8AcwBlAHQAdABhACAASQBuAHAAaABhAHIAbQBhAHQAaQBj ACAALgBkAG8AYwAEAEcAQgBNAEEARQBcAFwAaABvAG0AZQBzAFwAZgBiAGUA cgB0AG8AbgBcAGMAdgBcAGMAbwB2AGUAcgAgAGwAZQB0AHQAZQByACAAUwBp AGwAaQBjAG8AbgAgAEcAcgBhAHAAaABpAGMAcwAgAEIAaQBvAEkAbgBmAG8A cgBtAGEAdABpAGMAcwAgACAALgBkAG8AYwD/QAGAAQA/BgAAPwYAAPif8wBR AFEAPwYAAAAAAAA/BgAAAAAAAAIQAAAAAAAAAL0GAADgAAAIAEAAAAMAAABH FpABAAACAgYDBQQFAgMEh3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAAVABpAG0A ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYE AgICAgIEh3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAAIgAE ADEIiBgA8MQCAACpAQAAAACE82pmhPNqZgAAAAACAAAAAAD5AAAAjgUAAAEA AgAAAAQAAxALAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAPAQAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQA gAASMAAAEAAZAGQAAAAZAAAA0gYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA AAD//xIAAAAAAAAAEwBPAGMAdABvAGIAZQByACAAIAAzAHQAaAAgACwAIAAy ADAAMAAxAAAAAAAAAAUAcgBvAGMAYwBhAAQARwBCAE0AQQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf 8vlPaBCrkQgAKyez2TAAAAB4AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA tAAAAAQAAADAAAAABQAAANAAAAAGAAAA3AAAAAcAAADoAAAACAAAAPwAAAAJ AAAADAEAABIAAAAYAQAACgAAADQBAAAMAAAAQAEAAA0AAABMAQAADgAAAFgB AAAPAAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAA5AQAAB4AAAAUAAAAT2N0 b2JlciAgM3RoICwgMjAwMQAeAAAAAQAAAABjdG8eAAAABgAAAHJvY2NhAHIg HgAAAAEAAAAAb2NjHgAAAAEAAAAAb2NjHgAAAAsAAABOb3JtYWwuZG90AGge AAAABQAAAEdCTUEAbC5kHgAAAAIAAAAyAE1BHgAAABMAAABNaWNyb3NvZnQg V29yZCA4LjAAAEAAAAAAAAAAAAAAAEAAAAAAYCvQFIDCAUAAAAAAYCvQFIDC AQMAAAABAAAAAwAAAPkAAAADAAAAjgUAAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALV zdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkABAAD8AAAADAAA AAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAAEQAAAIwAAAAXAAAA lAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwAAAAM AAAA3AAAAAIAAADkBAAAHgAAAAEAAAAAAGUAAwAAAAsAAAADAAAAAgAAAAMA AADSBgAAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AB4QAAABAAAAFAAAAE9jdG9iZXIgIDN0aCAsIDIwMDEADBAAAAIAAAAeAAAA BgAAAFRpdHJlAAMAAAABAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAAC AAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAA ewAyAEMARQA3AEUAQQAzADcALQBCADcARQAyAC0AMQAxAEQANQAtAEEANwAz ADAALQAwADgAMAAwADEANwAwADgAMABGAEUAOAB9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAP7///8OAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAA/v///xYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAD+////HgAA AB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7////9////JwAAAP7////+//// /v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////UgBvAG8AdAAgAEUA bgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAADm DA8UgMIBwJpj2RSAwgEpAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA0AAAAAEAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBQAA AP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAB4YAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp AG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAAABAA AAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0AAAAAEAAAAAAAAAEA QwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBj AHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AMCaY9kUgMIBwJpj2RSAwgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARhgAAABEb2N1bWVudCBNaWNyb3NvZnQg V29yZAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA= --------------CC08D6435A2FC1849BCD8E57 Content-Type: application/msword; name="CV.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="CV.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAVAAAAAAAAAAAEAAAVgAAAAEAAAD+////AAAAAFMAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEAcQAMBAAACBK/AAAAAAAAEAAAAAAABAAA sBQAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAMBBYAHioAABZBAQAW QQEAsBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAACwCAAAA AAAALAIAACwCAAAAAAAALAIAAAAAAAAsAgAAAAAAACwCAAAAAAAALAIAABQA AAAAAAAAAAAAAEACAAAAAAAAQAIAAAAAAABAAgAAAAAAAEACAAAAAAAAQAIA ACQAAABkAgAAJAAAAEACAAAAAAAA5EQAALgBAACcAgAAFgAAALICAAAAAAAA sgIAAAAAAACyAgAAAAAAALICAAAAAAAAqwYAAAAAAACrBgAAAAAAAKsGAAAA AAAAqUQAAAIAAACrRAAAAAAAAKtEAAAAAAAAq0QAAAAAAACrRAAAAAAAAKtE AAAAAAAAq0QAACQAAACcRgAA9AEAAJBIAABYAAAAz0QAABUAAAAAAAAAAAAA AAAAAAAAAAAALAIAAAAAAACrBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvBgAA fAAAAKsGAAAAAAAAqwYAAAAAAACrBgAAAAAAAM9EAAAAAAAAAwoAAAAAAAAs AgAAAAAAACwCAAAAAAAAsgIAAAAAAAAAAAAAAAAAALICAAB9AwAAnAIAAAAA AAADCgAAAAAAAAMKAAAAAAAAAwoAAAAAAACrBgAAWAMAACwCAAAAAAAAsgIA AAAAAAAsAgAAAAAAALICAAAAAAAAqUQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA QAIAAAAAAABAAgAAAAAAACwCAAAAAAAALAIAAAAAAAAsAgAAAAAAACwCAAAA AAAAqwYAAAAAAACpRAAAAAAAAAMKAACABAAAAwoAAAAAAACDDgAAhgIAAKVC AADQAQAALAIAAAAAAAAsAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqUQAAAAAAACyAgAA AAAAAIgCAAAUAAAAAKm1WuZ9wgFAAgAAAAAAAEACAAAAAAAAAwoAAAAAAAB1 RAAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAARnLpZOlyaWMgIEJFUlRPTiAJCQkJCQkJCQkgDVF1YXJ0aWVyIGxl cyBUYWxsYWlyZXMJCQkJCQkJCQkgICAgICAgIAkNMTMxMjItIFZFTlRBQlJF TgkJCQkNKKA6ICgzMykgMDQuNDIuMjguODUuNzcNKCA6IBMgTElFTkhZUEVS VEVYVEUgIm1haWx0bzpGcmVkZXJpYy5CZXJ0b25AZXNpbC51bml2Lm1ycy5m ciIgARRGcmVkZXJpYy5CZXJ0b25AZXNpbC51bml2Lm1ycy5mchUNDUVuZ2lu ZWVyaW5nIFN0dWRlbnQgaW4gQmlvdGVjaG5vbG9neSANDQ0IDUVkdWNhdGlv biBhbmQgcXVhbGlmaWNhdGlvbnMNDQ0yMDAwIJYgMjAwMyA6IEVjb2xlIFN1 cOlyaWV1cmUgZCdJbmfpbmlldXJzIGRlIEx1bWlueSAoRVNJTCkgb2YgTWFy c2VpbGxlLiBFbmdpbmVlcmluZyBTY2hvb2wgc3BlY2lhbGl6aW5nIGluIHRo ZSBmaWVsZCBvZiBCaW90ZWNobm9sb2d5IGFuZCBCaW9pbmZvcm1hdGljcy4g RXF1aXZhbGVuY2UgOiBNYXN0ZXIgb2YgU2NpZW5jZSBEZWdyZWUgJiBQcmUt RG9jdG9yYXRlIFByZXBhcmF0aW9uLiBNYWpvciBTdWJqZWN0cyA6IG1pY3Jv YmlvbG9neSwgZ2VuZXRpY3MsIGJpb2luZm9ybWF0aWMgOiBzZXF1ZW5jZSBh bGlnbmVtZW50LCBwaHlzaWNhbCBtYXBwaW5nIGFuZCBmdW5jdGlvbm5hbCBh bm5vdGF0aW9ucywgZGF0YWJhc2UsIHByb2dyYW1taW5nIGFuZCBiaW9zdGF0 aXN0aWNzLCB2aXJvbG9neSwgYmlvY2hlbWlzdHJ5LCBlbnp5bW9sb2d5LCBl Y29ub21pY3MuIFNjaG9vbCBQcm9qZWN0cyA6IGZ1bmN0aW9uYWwgYW5hbHlz aXMgb2YgYSBwcm90ZWluIGZhbWlseSwgYmlibGlvZ3JhcGhpYyBwcm9qZWN0 IG9uIHRoZSBMYWItb24tY2hpcA0NMTk5OCCWIDIwMDAgOiBEVVSgOiBEaXBs 9G1lIFVuaXZlcnNpdGFpcmUgZW4gZ+luaWUgYmlvbG9naXF1ZSBvcHRpb24g aW5kdXN0cmllIGFsaW1lbnRhaXJlIGV0IGJpb2xvZ2lxdWUgd2l0aCBob25v dXJzLiBBdmlnbm9uIJYgQUdST1BBUkMuIEEgdHdvLXllYXIgdGVjaG5pY2Fs IG9yaWVudGVkIHVuZGVyZ3JhZHVhdGUgZGVncmVlLCBzcGVjaWFsaXNlZCBp biBiaW9sb2d5LCBtaWNyb2Jpb2xvZ3kgYW5kIHRoZSBmb29kIGluZHVzdHJ5 DQ0NMTk5NiCWIDE5OTggOiBUd28teWVhciBwcmUtbWVkaWNhbCBjb3Vyc2Ug KENlbnRyZSBVbml2ZXJzaXRhaXJlIJYgSPRwaXRhbCBOT1JEIGFuZCBMQSBU SU1PTkUgliBNYXJzZWlsbGUpDQ0xOTk2ICAgICAgICAgICAgIDogQmFjY2Fs YXVy6WF0LCBHZW5lcmFsIFNlY29uZGFyeSBFZHVjYXRpb24gKEhpZ2ggU2No b29sIERpcGxvbWEpIFNjaWVudGlmaWMsIG9wdGlvbiBsaWZlIGFuZCBlYXJ0 aCAgICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgICBz Y2llbmNlcywgd2l0aCBkaXN0aW5jdGlvbiANDQgNV29yayBFeHBlcmllbmNl DQ0NMjAwMqA6IEludGVybnNoaXA6IKugQ2FydG9ncmFtIG9mIHRoZSBjb21w bGV0ZWx5IHNlcXVlbmNlZCBvcmdhbmlzbXOguy4gQ3JlYXRpb24gb2YgYW4g aW5mb3JtYXRpYyB0b29sICh1c2luZyANMiBtb250aHMgCVBIUCwgSFRNTCwg UGVybCkgd2hpY2ggZW5hYmxlcyB0aGUgaW50ZXJjb25uZXhpb24gd2l0aCBh IGRhdGFiYXNlIGFuZCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcmVzdWx0cyBm b3IgQXJjaGFlYSBvcmdhbmlzbXMuIEFGTUIgKEFyY2hpdGVjdHVyZSBldCBG b25jdGlvbiBkZXMgTWFjcm9tb2zpY3VsZXMgQmlvbG9naXF1ZXMpIGluIHRo ZSBMYWJvcmF0b3J5IG9mIGdseWNvYmlvbG9neSwgQ05SUyAoTmF0aW9uYWwg Q2VudHJlIG9mIFNjaWVudGlmaWMgUmVzZWFyY2gpIJYgTWFyc2VpbGxlDQ0y MDAxoDogSW50ZXJuc2hpcCA6IKugRXZhbHVhdGlvbiBvZiB0aGUgcHJvYmxl bXMgaW4gcHJvZHVjdGlvbiBvZiBhaXJsaW5lIGZvb2QgY2F0ZXJpbmcgYW5k IGZvcm11bGF0aW9uIG9mIGNvcnJlY3RpdmUgDSAgICAgIDIgbW9udGhzICAg ICAgICAgIG1lYXN1cmVzILsuIHN0YWZmIG1hbmFnZW1lbnQsIHByaWNlIHJl ZHVjdGlvbiwgaW1wcm92ZW1lbnQgb2YgdGhlIHF1YWxpdHkgc3lzdGVtIGFu ZCBvcmdhbml6YXRpb24gb2YgDSBtZWV0aW5ncy4gQ0FUQUlSIJYgTWFyaWdu YW5lDQ0yMDAwoDogVGVjaG5pY2lhbiBpbiBsYWJvcmF0b3J5IG9mIGFuYWx5 c2lzIChhbmFseXNlcyBhbmQgc3R1ZHkgb24gYXJvbWF0aWNzIGFuZCBwZXRy b2xldW0gcHJvZHVjdHMpoDogbG90IG9mDTIgbW9udGhzICAgICAgICAgYW5h bHlzaXMsIGdhc2VvdXMgcGhhc2UgY2hyb21hdG9ncmFwaHkgKEdhcyBjaHJv bWF0b2dyYXBoeSksIGRpc3RpbGxhdGlvbi4gU0hFTEwgLSBCZXJyZSBsJ0V0 YW5nDQ0yMDAwoDogSW50ZXJuc2hpcCBJVVQgOiCroExvdyB0ZW1wZXJhdHVy ZSBncm93dGgsIHRoZXJtb3Jlc2lzdGFuY2Ugb2YgQmFjaWxsdXMgY2VyZXVz IHN0cmFpbnMgaXNvbGF0ZWQgb24gdGhlIA0gICAyIG1vbnRocyAgICAgICAg IHByb2R1Y3Rpb24gbGluZSBvZiBwcm9jZXNzZWQgY291cmdldHRlIHB1cmVl oLsuIFNjaGVkdWxpbmcgb2YgZXhwZXJpbWVudHMsIGJpYmxpb2dyYXBoaWMg c3R1ZHksDSAgICAgICAgICAgICAgICAgICAgICAgICAgIGhhbmRsaW5nIGdl cm1zLiBJTlJBIC0gQXZpZ25vbiANDTE5OTkgliAxOTk3IDogQWdyaWN1bHR1 cmFsIHdvcmtlciB3aXRoIGFuIGluZGVwZW5kZW50IGZhcm1lciBwcm9kdWNl ciAobWVsb25zLCB0b21hdG9lcywgc2FsYWRzLCBjb3VyZ2V0dGVzIGluDSAg ICAgIDQgbW9udGhzICAgICAgICAgICBncmVlbmhvdXNlIGdyb3dpbmcpLCBw cmFjdGljYWwgYXBwbGljYXRpb24gb2YgdGhlIG5hdHVyZS1mcmllbmRseSBw ZXN0aWNpZGVzDQ0xOTk4IJYgMTk5NyA6IEEuUy5IIChBZ2VudCBvZiB0aGUg SG9zcGl0YWyScyBzZXJ2aWNlcykgliBIb3NwaXRhbCBoeWdpZW5lIJYgYXQg Q2VudHJlIEhvc3BpdGFsaWVyIGR1IFBheXMgDSAgICAgIDIgbW9udGhzICAg ICAgICAgICBkJ0FpeC1lbi1Qcm92ZW5jZSBldCBhdSBDZW50cmUgZGUgTW95 ZW4gZXQgTG9uZyBz6WpvdXIgUm9nZXIgRHVxdWVzbmUNDQ0NDQ0NDQhTcGVj aWFsIGtub3dsZWRnZQ0NDUluZm9ybWF0aWNzIDogb24gUEMsICBXaW5kb3dz LCBMaW51eCBhbmQgVW5peCwgT2ZmaWNlLCBQZXJsLCBKYXZhLCBQSFAsIEhU TUwsIFNRTCwgV2ViIHBhZ2UgZGV2ZWxvcG1lbnQsDSAgICBMYWJ2aWV3LCBS YXNtb2wuIEdvb2Qgd29ya2luZyBrbm93bGVkZ2UgaW4gdmlkZW8gc29mdHdh cmVzoDogUGhvdG9zaG9wIDcuMCwgUHJlbWllcmUgNi4wLA0gICAgSWxsdXN0 cmF0b3IgMTAsIERyZWFtd2VhdmVyLCBTb3VuZCBGb3JnZSA1LjUsIFdpbm1v cnBoLCBydWRpbWVudCBmb3IgQXV0b2NhZC4gDQ1MYW5ndWFnZXMgIDogIEVu Z2xpc2g6IHNjaWVudGlmaWMgCQkJCQkJCQkJCQkJICAgICAgICAgICAgICAg ICAgIEl0YWxpYW4gOiBnb29kIGxldmVsIChsaW5ndWlzdGljIHN0YXkgNiB3 ZWVrcykNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyZW5jaCA6 IG1vdGhlciB0b25ndWUNDQ0IDU1pc2NlbGxhbmVvdXMNDQ1TY2hvb2wgQWN0 aXZpdGllcyA6IC0gZXhwYW5zaW9uIG9mIHRoZSBXZWIgc2l0ZSwgY29uc3R1 Y3Rpb24gb2YgYW4gaW50ZXJhY3RpdmUgcXVlc3Rpb25uYWlyZSBmb3IgZm9y bWVyIHN0dWRlbnRzLiBPcmdhbml6ZWQgdGhlIJOgZm9ydW0gUEFDQSAyMDAy IJMgKHJlZ2lvbmFsIGZvcnVtKSBhbmQgb3JnYW5pemVkIGNvbnRhY3RzIHdp dGggZW50ZXJwcmlzZXMNICAtIEluIGNoYXJnZSBvZiBFU0lMIFRWIDIwMDKg OiBhZG1pbmlzdHJhdGVkIHRoZSBidWRnZXQsIHRoZSBlcXVpcG1lbnQgb2Yg dGhlIHRlYW1zLCAgIGRpcmVjdGVkIHRoZSBjb3ZlcmFnZSBvZiBNYXJzZWls bGUsIGRpcmVjdGVkIGEgZmlsbSBvbiB0aGUgc2Nob29sIGFuZCBvbiB0aGUg ZXZlbnRzIG9mIE1hcnNlaWxsZSwgd2Vla2x5IGJpZyBzY3JlZW4gcHJvamVj dGlvbnMuDQ1TcG9ydHMgOiBCYXNrZXRiYWxsLCBjaGFtcGlvbiBvZiBQcm92 ZW5jZSAxOTk1IChBLlMuUC5ULlQuICBBSVgpLCBoaWtpbmcsIHBpbmctcG9u ZywgZGl2aW5nIChsZXZlbCBJSUkpLCBydWdieS4NDUhvYmJpZXMgOiBBcXVh cmlvcGhpbGlhLCAgc3RhbXAgY29sbGVjdGluZywgbXVzaWMgKHJvY2ssIGJs dWVzKSwgc2NpZW50aWZpYyBwYXBlcnMgOiCroEJpby1mdXR1cqC7IChvbiBi aW90ZWNobm9sb2d5KS4NDQ1Ucmlwc6A6IE1leGljbywgTWFydGluaXF1ZSwg R3VhZGVsb3VwZSwgVGhh72xhbmQsIFR1bmlzaWEsIEVneXB0LCBFbmdsYW5k LCBJdGFseSwgUG9ydHVnYWwNDUNoaWxkcmVuknMgY2VudGVyIHN1cGVydmlz b3INAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAABwEAABFBAAAVgQAAFoEAABb BAAAXQQAAHIEAABzBAAAdAQAAHUEAAB2BAAAdwQAALEEAACyBAAAswQAANME AADUBAAA1QQAANYEAAD8BAAA/gQAAP8EAAAABQAAHAUAAB0FAAAfBQAAKgUA ACwFAAAtBQAAWwUAAGoFAACKBQAAvAUAAMcFAAD28e/r4NjxzdjHxL3Es72t vQCpnJmMg3l1mXFva2dkXlleAAAAAAhDShYAbUgJCAALNQiBQ0oWAG1ICQgE Q0oWAAAHNgiBQ0oWAAc1CIFDShYAAzUIgQY1CIE+KgEAB0IqCW1ICQgTQioJ Q0ocAE9KAABRSgAAbUgJCBBDShwAT0oAAFFKAABtSAkIABkDagAAAABDShwA T0oAAFFKAABVCAFtSAAEBG1ICQgAGTYIgTkIgUIqCUNKLABPSgAAUUoAAG1I CQgHQioJQ0oUAAswSg8AQioAQ0oYABMCCIEDagAAAAAGCAFDShgAVQgBDQNq AAAAAENKGABVCAEEQ0oYAAAKNQiBNgiBQ0oYAAAUCWoDACrwNQiBNgiBT0oA AFFKAAAADjUIgTYIgU9KAABRSgAAABQJagMAKPA1CIE2CIFPSgAAUUoAAAAG NQiBNgiBAAM2CIEIT0oAAFFKAAAAEjUIgTYIgU9KAABRSgAAbUgJCCIABAAA HAQAAEUEAABaBAAAcgQAANUEAADWBAAA/AQAAP0EAAD+BAAAAAUAAB0FAAAe BQAAHwUAADgHAAA5BwAAMwgAADQIAAA1CAAAnwgAAKAIAAAkCQAAWwkAAFwJ AABeCQAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOgAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADVAAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACAAACiYAC0YWAA3GBAFoAQADAAADJAMABgAA AyQDCiYAC0YWAAkAAAomAAtGFgAPhFQGEYSs+QMCAAMkAQMEAAMkAQABBAAA AQAAAAEGAAABAQAAGAAEAAAcBAAARQQAAFoEAAByBAAA1QQAANYEAAD8BAAA /QQAAP4EAAAABQAAHQUAAB4FAAAfBQAAOAcAADkHAAAzCAAANAgAADUIAACf CAAAoAgAACQJAABbCQAAXAkAAF4JAABuCQAAbwkAAHAJAADfCQAAAAsAAAEL AAB4CwAA9gsAABQMAAAVDAAAgwwAAPUMAAD2DAAAZQ0AANkNAAAUDgAAFQ4A APz28+3n5N7b2NLMycbAvbWyr6eknJmWk42Kh4EAAHsAAAB1AABvAAAAAAAA AAAAAAAAAAAAAAoIFwAJAQoDAAAAAAoIFwAJAQoCAAAAAAoIFwAJAQoBAAAA AAoG7v///wgXAAkBAAUG7////wUG8P///woCAwAFAgai+///AAUGpPv//wUG pfv//wUG3Pv//w8GYPz//wgWAAkBCgMAAAAFBmH8//8PBsv8//8IFgAJAQoC AAAABQbM/P//BQbN/P//DwbH/f//CBYACQEKAQAAAAUGyP3//woG4f///wgW AAkBAAUG4v///wUG4////woCAgAFAQYA////AAoCBAAFAwYC////AAUG2f// /wUG2v///woCBAAFAwYq////AAUGnf///woCBAAFAwaO////AAoCBAAFAwam ////AAUG1////woCBgAFBQbk////AAUCAQAFAAApxwUAAAAGAAAOBgAA1AYA AOMGAAA5BwAARAcAAEYHAABHBwAAoQcAALAHAAC4BwAAugcAAMIHAADEBwAA NQgAAEAIAABCCAAAnggAAKAIAAClCAAAsggAALMIAADzCAAA/QgAACMJAAAk CQAAPwkAAFsJAABcCQAAXQkAAF4JAABuCQAAcAkAAHQJAAB3CQAAggkAALgJ AABkCgAAaAoAAMQKAADLCgAAAQsAAAULAAAGCwAACAsAABcLAAABDAAABwwA ABQMAAAVDAAAGQwAABwMAABADAAAggwAAIMMAADfDAAA5QwAAPQMAAD2DAAA +gwAAPsMAAD9DAAADA0AAA0NAAAQDQAAPA0AAEsNAABkDQAAZQ0AAKUNAACm DQAAqQ0AAAQOAAAKDgAA+/X79fvx7+zo7Pv1+/X74t779eLe9fv1+9je+9jN 2MTB8ey97Pu97L3s4sH79fv1+8Hi+/X79fu97L3xAOy97L3s6Oz17L3s+/UA AAAABzUIgUNKFgAEbUgJCAARNgiBPioBQioJQ0ocAG1ICQgUA2oAAAAANQiB Q0oUAFUIAW1IAAQACzUIgUNKHABtSAkIBzUIgW1ICQgKNQiBPioBbUgJCAAH NgiBQ0oWAARDShYAAAM1CIEGNQiBPioBAAs1CIFDShYAbUgJCAhDShYAbUgJ CEpeCQAAbgkAAG8JAABwCQAA3wkAAAALAAABCwAAeAsAAPYLAAAUDAAAFQwA AIMMAAD1DAAA9gwAAGUNAADZDQAAFA4AABUOAACEDgAA6g4AAOsOAABWDwAA tQ8AALYPAAD8AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA5QAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAANAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAMgA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAABQAA CiYAC0YXAAMAAAMkAwcAAAMkAw+EVAYRhGD6BwAAAyQDD4TqBhGEfvoHAAAD JAMPhOwEEYRoAQcAAAMkAw+EVAYRhKz5BwAAAyQDD4SfBhGEyfoABgAAAyQD CiYAC0YXAAABAAADAwADJAEAFwoOAAATDgAAFQ4AACAOAAAhDgAAIg4AAIMO AACEDgAAjA4AAJIOAACvDgAAsQ4AALIOAADpDgAA6g4AAOsOAAD2DgAAJA8A ADcPAABVDwAAVg8AAFwPAABeDwAAZA8AAG8PAAC5DwAAug8AALwPAAC9DwAA zg8AAM8PAADRDwAA3A8AAN4PAAA6EAAAPRAAAOwQAAD1EAAA+hAAAAERAAAD EQAAGhEAADcRAABcEQAAgxEAAJQRAACVEQAAlhEAAKQRAACmEQAAtxEAAHIS AABzEgAAkBIAANgSAADtEgAATRMAAFMTAABVEwAAvhMAAMUTAADGEwAA+/Xv 6+j74Oj76Pvg9eD77/v1+/XoAN0A3dkAzcO26O/r++v77+vg9fvg++D7q6eb 6O/76Ovo6+jv6/vv6wAWNgiBQioJQ0ocAE9KAABRSgAAbUgJCAAHNgiBbUgJ CBQDagAAAAA1CIFDShQAVQgBbUgABAAZNQiBPioAQioJQ0ocAE9KAABRSgAA bUgJCBNCKglDShwAT0oAAFFKAABtSAkIFwNqAAAAADUIgUIqCUNKFABVCAFt SAAEBzUIgUNKFgAEQ0oWAAAONQiBNgiBQ0oWAG1ICQgABG1ICQgABzUIgW1I CQgKNQiBPioBbUgJCAALNQiBQ0oWAG1ICQgIQ0oWAG1ICQg9FQ4AAIQOAADq DgAA6w4AAFYPAAC1DwAAtg8AALcPAAC4DwAAuQ8AALoPAAC7DwAAvA8AAM8P AADQDwAA0Q8AADoQAACYEAAA6xAAAOwQAABcEQAAkhEAAJMRAACUEQAAlhEA AKQRAAClEQAAphEAAHMSAABMEwAATRMAAL0TAAC+EwAANRQAADYUAAA3FAAA khQAAJMUAACwFAAA+gAA9AAAAAAAAAAA8e7r5QAAAOIAAAAA3wAA3AAA4gDi AADiAOIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCBUACQEFAgUABQQFCAEACQEK Buv///8IEgAJAQAFBuz///8FBu3///8FAgIABQEKCBcACQEKBQAAAAAKCBcA CQEKBAAAACa2DwAAtw8AALgPAAC5DwAAug8AALsPAAC8DwAAzw8AANAPAADR DwAAOhAAAJgQAADrEAAA7BAAAFwRAACSEQAAkxEAAJQRAACWEQAApBEAAKUR AACmEQAAcxIAAEwTAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADwAAAA AAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADoAAAAAAAAAAAA AAAA4wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2wAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAAAA AAAABwAAAyQDD4QkCRGETP8JAAAKJgALRhUAD4QkCRGE3PYDBQADJAEAAwAA EYTEAgADAAAPhEwIBQAACiYAC0YBAAMAAAMkAwUAAAMkAw+EiAUKAAADJAMK JgALRhIADcYEAWgBAAMCAAMkAQABAAAAF0wTAABNEwAAvRMAAL4TAAA1FAAA NhQAADcUAACSFAAAkxQAALAUAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAAUAAAomAAtGAQAHAAADJAMPhBALEYTzAAAJxhMA AMgTAAA3FAAAPRQAAD8UAACwFAAA+fTu+fQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKNQiBPioBbUgJCAAIQ0oWAG1ICQgA CzUIgUNKFgBtSAkIAAUcAB+wgi4gsMZBIbA3AiKwNwIjkLQAJJBoASWwAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcBAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAACEAAABGAHIAZQBk AGUAcgBpAGMALgBCAGUAcgB0AG8AbgBAAGUAcwBpAGwALgB1AG4AaQB2AC4A bQByAHMALgBmAHIAAADgyep5+brOEYyCAKoAS6kLUAAAAG0AYQBpAGwAdABv ADoARgByAGUAZABlAHIAaQBjAC4AQgBlAHIAdABvAG4AQABlAHMAaQBsAC4A dQBuAGkAdgAuAG0AcgBzAC4AZgByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABAACgABAFsADwAC AAAAAAAAADgAAEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgA X0gBBGFKGABtSAwEc0gMBHRIDAQ4AAFAAQACADgADAAHAFQAaQB0AHIAZQAg ADEAAAAIAAEABiQBQCYAEABDShwAT0oEAFFKBABhShQAPgACQAEAAgA+AAwA BwBUAGkAdAByAGUAIAAyAAAACAACAAYkAUAmARUANQiBNgiBPioBT0oFAFFK BQBhShQAADAAA0ABAAIAMAAMAAcAVABpAHQAcgBlACAAMwAAAAgAAwAGJAFA JgIHADUIgWFKFAAAPgAEQAEAAgA+AAwABwBUAGkAdAByAGUAIAA0AAAACAAE AAYkAUAmAxYANQiBNgiBQ0oUAE9KBgBRSgYAYUoUADoABUABAAIAOgAMAAcA VABpAHQAcgBlACAANQAAAAgABQAGJAFAJgQSADUIgT4qAU9KBQBRSgUAYUoU ADYABkABAAIANgAMAAcAVABpAHQAcgBlACAANgAAAAgABgAGJAFAJgUOADYI gU9KBgBRSgYAXAiBAAAAAAAAMgBBQPL/oQAyAAwAEQBQAG8AbABpAGMAZQAg AHAAYQByACAAZADpAGYAYQB1AHQAAAAAAAAAAAAAAAAAOgBVQKIA8QA6AAwA DwBMAGkAZQBuACAAaAB5AHAAZQByAHQAZQB4AHQAZQAAAAwAPioBQioCcGgA AP8AAAAAALAQAAAIAAAqAAAAAP////8ABAAAxwUAAAoOAADGEwAAsBQAAAsA AAAOAAAAEAAAABQAAAAABAAAXgkAALYPAABMEwAAsBQAAAwAAAAPAAAAEgAA ABMAAAAABAAAFQ4AALAUAAANAAAAEQAAAHYAAACyAAAA0wAAALAQAAATWBT/ FYQPAADwWAAAAAAABvAYAAAAAggAAAIAAAAGAAAAAQAAAAEAAAAHAAAAYAAa 8RgAAAAAM8wAM2b/AGaZ/wCZzP8A///MAOrq6gBAAB7xEAAAAP//AAAAAP8A gICAAPcAABAADwAC8BQDAAAQAAjwCAAAAAUAAAAGBAAADwAD8LICAAAPAATw KAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAP AATwnAAAABIACvAIAAAAAwQAAAAKAACDAAvwXgAAAIABBwAAAIEB6urqAIMB wMDAAIwBzv///78BFAAUAP8BAAAIAIPDLgAAAL8DIABgAAUACAAIAOP///8A AAAA4////whSAABgVAAACFIAAGBUAAAAAAAA4////wAAAAAAABDwBAAAAAAA AAAAABHwBAAAAAsAAAATACLxBgAAAL8DAAAAgA8ABPCcAAAAEgAK8AgAAAAE BAAAAAoAAIMAC/BeAAAAgAEHAAAAgQHq6uoAgwHAwMAAjAHO////vwEUABQA /wEAAAgAg8MuAAAAvwMgAGAABQAIAAgA4////wAAAADj////CFIAAGBUAAAI UgAAYFQAAAAAAADj////AAAAAAAAEPAEAAAAAQAAAAAAEfAEAAAAHQAAABMA IvEGAAAAvwMAAACADwAE8I4AAAASAArwCAAAAAUEAAAACgAAgwAL8F4AAACA AQcAAACBAerq6gCDAcDAwACMAc7///+/ARQAFAD/AQAACACDwy4AAAC/AyAA YAAFAAgACADj////AAAAAOP///8IUgAAYFQAAAhSAABgVAAAAAAAAOP///8A AAAAAAAQ8AQAAAACAAAAAAAR8AQAAAAqAAAADwAE8JwAAAASAArwCAAAAAYE AAAACgAAgwAL8F4AAACAAQcAAACBAerq6gCDAcDAwACMAc7///+/ARQAFAD/ AQAACACDwy4AAAC/AyAAYAAFAAgACADj////AAAAAOP///8IUgAAYFQAAAhS AABgVAAAAAAAAOP///8AAAAAAAAQ8AQAAAADAAAAAAAR8AQAAAAOAAAAEwAi 8QYAAAC/AwAAAIAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8B AAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP4AAABc BQAAvAsAAJQNAACwEAAAAwQAAAAAAACpAAAAmCsAAMUCAAB0QAAAAAAEBAAA AAAAALsAAACYKwAA1wIAAHRAAAAAAAUEAABM////TP///+QqAABoAQAAdEAA AAAABgQAAAAAAACDAAAAmCsAAJ8CAAB0QAAAAAAAAAAACAAAACkAAAAyAAAA TgEAAFQBAAB9AQAAiQEAAKwBAAC6AQAAKQIAADYCAABCAgAATAIAAGMCAABu AgAAlgIAAKMCAAC9AgAAxwIAAKIDAACmAwAApwMAAK4DAACwAwAAtwMAAGcE AAB0BAAAdwQAAH4EAACUBAAAnQQAALMEAAC/BAAAdwUAAIEFAACFBQAAjgUA AJIFAACVBQAAlgUAAKAFAAChBQAAqgUAAKsFAAC0BQAAxwUAANEFAAD0BQAA +AUAAAwGAAAaBgAAUQYAAFgGAACmBgAAqQYAAKoGAAC0BgAAuAYAAMQGAADf BgAA6QYAAOUHAADxBwAACggAABMIAAD9CAAABwkAABAJAAATCQAAFAkAAB8J AAAgCQAAJgkAACgJAAA4CQAAPAkAAEQJAABFCQAASwkAAEwJAABTCQAAVAkA AFwJAABgCQAAYwkAAGoJAABwCQAAhAkAAIgJAACMCQAAlQkAAKAJAAClCQAA CwoAABIKAABBCwAATAsAAF4LAABkCwAA0QsAANwLAADwCwAA9QsAAAgMAAAM DAAAPgwAAEUMAABHDAAATQwAAG8MAAB4DAAAewwAAIQMAACsDAAAtwwAAMoM AADSDAAA4QwAAOgMAADXDQAA4g0AABgOAAAhDgAATw4AAFgOAADkDgAA7Q4A ACIPAAArDwAAbg8AAHYPAACXDwAAoA8AAMgPAADVDwAAGRAAAB4QAABfEAAA ZxAAAJ4QAACkEAAAshAAABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA//8UAAAADQBDAHIAYQBp AGcAIABEAGEAbgBpAGUAbABzAFIAQwA6AFwAUAByAG8AZwByAGEAbQAgAEYA aQBsAGUAcwBcAEEATwBMACAANwAuADAAXABkAG8AdwBuAGwAbwBhAGQAXABs AGUAdAB0AHIAZQBtAG8AdABpAHYAYQB0AGkAbwBuAGUAbgBnAGwAaQBzAGgA XwBuAGUAdwB6AGUAYQBsAGEAbgBkAFwAQwBWAEEATgBHAEwAQQBJAFMALgBk AG8AYwAEAGYAcgBlAGQAdABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEA bgBkACAAUwBlAHQAdABpAG4AZwBzAFwAYgBlAHIAdABvAG4AIABmAHIAZQBk AGUAcgBpAGMAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwA TQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwARQBuAHIAZQBnAGkAcwB0 AHIAZQBtAGUAbgB0ACAAYQB1AHQAbwBtAGEAdABpAHEAdQBlACAAZABlAEMA VgBBAE4ARwBMAEEASQBTAC4AYQBzAGQABABmAHIAZQBkAEsAQwA6AFwARABv AGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGIA ZQByAHQAbwBuACAAZgByAGUAZABlAHIAaQBjAFwATABvAGMAYQBsACAAUwBl AHQAdABpAG4AZwBzAFwAVABlAG0AcABcAEMAVgBBAE4ARwBMAEEASQBTAC4A ZABvAGMABABHAEIATQBBACEAXABcAGgAbwBtAGUAcwBcAGYAYgBlAHIAdABv AG4AXABjAHYAXABhAG4AZwBsAGEAaQBzAFwAQwBWAC4AZABvAGMABABHAEIA TQBBACEAXABcAGgAbwBtAGUAcwBcAGYAYgBlAHIAdABvAG4AXABjAHYAXABh AG4AZwBsAGEAaQBzAFwAQwBWAC4AZABvAGMABABHAEIATQBBACEAXABcAGgA bwBtAGUAcwBcAGYAYgBlAHIAdABvAG4AXABjAHYAXABhAG4AZwBsAGEAaQBz AFwAQwBWAC4AZABvAGMABABHAEIATQBBACEAXABcAGgAbwBtAGUAcwBcAGYA YgBlAHIAdABvAG4AXABjAHYAXABhAG4AZwBsAGEAaQBzAFwAQwBWAC4AZABv AGMABABHAEIATQBBACEAXABcAGgAbwBtAGUAcwBcAGYAYgBlAHIAdABvAG4A XABjAHYAXABhAG4AZwBsAGEAaQBzAFwAQwBWAC4AZABvAGMABABHAEIATQBB ACEAXABcAGgAbwBtAGUAcwBcAGYAYgBlAHIAdABvAG4AXABjAHYAXABhAG4A ZwBsAGEAaQBzAFwAQwBWAC4AZABvAGMABABHAEIATQBBACEAXABcAGgAbwBt AGUAcwBcAGYAYgBlAHIAdABvAG4AXABjAHYAXABhAG4AZwBsAGEAaQBzAFwA QwBWAC4AZABvAGMAFwBvDVkL+tBkKP8PAAAAAAAAAAAAAAAAAAAAAAEADgvM EBDfuIz/D/8P/w//D/8P/w//D/8P/w8QABMghBXwfvIA/w//D/8P/w//D/8P /w//D/8PEACSWCAbkOGESf8P/w//D/8P/w//D/8P/w//DxAArydzJ/ybtj// D/8P/w//D/8P/w//D/8P/w8QANcL4Sh8Ce7O/w//D/8P/w//D/8P/w//D/8P EAAoVMoq1FPirf8P/w//D/8P/w//D/8P/w//DxAAiWjHLba7ajP/D/8P/w// D/8P/w//D/8P/w8QAAxMYjDu3HzQ/w//D/8P/w//D/8P/w//D/8PEABjFR40 6jECVP8P/w//D/8P/w//D/8P/w//DxAAG1xDOrx6unH/D/8P/w//D/8P/w// D/8P/w8QAF8M4T7wYn6o/w//D/8P/w//D/8P/w//D/8PEABhcgBAZkGUgP8P /w//D/8P/w//D/8P/w//DxAAQVtyQqj/VBn/D/8P/w//D/8P/w//D/8P/w8Q AHZjIUhAWGwC/w//D/8P/w//D/8P/w//D/8PEAACahFQENjgQv8PAAAAAAAA AAAAAAAAAAAAAAEAeTYpWWZBlID/D/8P/w//D/8P/w//D/8P/w8QAIcdWVsO //LX/w//D/8P/w//D/8P/w//D/8PEACXSIBd0ld6/P8P/w//D/8P/w//D/8P /w//DxAA6kFVc9T2qr7/D/8P/w//D/8P/w//D/8P/w8QACdzy3fwfvIA/w// D/8P/w//D/8P/w//D/8PEACpedB8gvOyP/8P/w//D/8P/w//D/8P/w//DxAA VW+WfzoYpL7/D/8P/w//D/8P/w//D/8P/w8QAAoAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAA4YAJUPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP42CABPSgAAUUoA AG8oAAEALQABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4V xgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBABRSgQA bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXG BQABCAcGXoQIB2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYF AAGoDAZehKgMYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8o AAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUA AUgSBl6ESBJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KBABRSgQAbygA AQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB 6BcGXoToF2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYFAAGg BQZehKAFYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgMAUUoDAG8oAAEA p/ABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUAL Bl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABRSgQAbygAAQBv AAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAG XoTgEGCEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfw AQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgMAUUoDAG8oAAEAp/AB AAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6E aAFghJj+T0oDAFFKAwBvKAABANjwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBABRSgQAbygAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQI B2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBvKAABALfwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZehKgM YISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJg hJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KBABRSgQAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CE mP5PSgMAUUoDAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY /k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+ T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E qAwRhJj+FcYFAAGoDAZehKgMYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5P SgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RI EhGEmP4VxgUAAUgSBl6ESBJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9K BABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgX EYSY/hXGBQAB6BcGXoToF2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAFxAAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgMA UUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RACxGE mP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABR SgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY /hXGBQAB4BAGXoTgEGCEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFK AQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+ FcYFAAGAFgZehIAWYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAA AABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgMAUUoD AG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4V xgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBABRSgQA bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXG BQABCAcGXoQIB2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYF AAGoDAZehKgMYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8o AAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUA AUgSBl6ESBJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KBABRSgQAbygA AQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB 6BcGXoToF2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEI BwZehAgHYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgMAUUoDAG8oAAEA p/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagM Bl6EqAxghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBABRSgQAbygAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIG XoRIEmCEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oBAFFKAQBvKAABALfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZe hOgXYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhLgaEYSY/hXGBQABuBoGXoS4GmCEmP5PSgMAUUoDAG8oAAEAp/DN BwAAAAABAAAAAAAAAAAAAAAAAAAAAAANGAAAD4TAAxGEqP0VxgUAAcADBl6E wANghKj9NggAPioBQ0oYAG8oAAEAAAABAAAABIABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKCAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIA AgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEA AAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAEAAAAXEAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Sg BRGEmP4VxgUAAaAFBl6EoAVghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9K AwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oE AFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E4BAR hJj+FcYFAAHgEAZehOAQYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KAwBR SgMAbygAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oEAFFK BABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+ FcYFAAEIBwZehAgHYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAA AABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgEAUUoB AG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4V xgUAAagMBl6EqAxghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KAwBRSgMA bygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXG BQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oEAFFKBABv KAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYF AAHoFwZehOgXYISY/k9KAwBRSgMAbygAAQCn8BUAAAAXEAAAAAAAAAAAAAAA AAAAAAAAAAYYAJUPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP41CAFvKAABAC0A AQAAABcQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgMAUUoDAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABRSgQAbygAAQBvAAEA AAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAA ABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgMAUUoDAG8oAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFg hJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBABRSgQAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CE mP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY /k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+ T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E GBURhJj+FcYFAAEYFQZehBgVYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP5P SgMAUUoDAG8oAAEAp/AVAAAAFxAAAAAAAAAAAAAAAAAAAAAAAAAGGACVD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+NQgBbygAAQAtAAEAAAAXEAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgQAUUoE AG8oAAEAbwABAAAAFxAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4V xgUAAXAIBl6EcAhghJj+T0oDAFFKAwBvKAABAKfwAQAAABeQAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEA bygAAQC38AEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP5PSgQAUUoEAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oDAFFKAwBv KAABAKfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgQAUUoEAG8o AAEAbwABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUA AVAZBl6EUBlghJj+T0oDAFFKAwBvKAABAKfwFQAAABcQAAAAAAAAAAAAAAAA AAAAAAAABhgAlQ+EaAERhJj+FcYFAAFoAQZehGgBYISY/jUIAW8oAAEALQAB AAAAF5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6E oAVghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KAwBRSgMAbygAAQCn8AEA AAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRA C2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oEAFFKBABvKAABAG8AAQAA ABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQ YISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAA F5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZg hJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KAwBRSgMAbygAAQCn8BUAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAYYAJUPhGgBEYSY/hXGBQABaAEGXoRoAWCE mP41CAFvKAABAC0AFQAAABcQAAAAAAAAAAAAAGgBAAAAAAAABhgAlQ+EaAER hJj+FcYFAAFoAQZehGgBYISY/jUIAW8oAAEALQABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oEAFFKBABv KAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYF AAEIBwZehAgHYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgEAUUoBAG8o AAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUA AagMBl6EqAxghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KAwBRSgMAbygA AQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQAB SBIGXoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oEAFFKBABvKAAB AG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHo FwZehOgXYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgEAUUoBAG8oAAEA t/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgH Bl6ECAdghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAwBRSgMAbygAAQCn 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwG XoSoDGCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oEAFFKBABvKAABAG8A AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZe hEgSYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgEAUUoBAG8oAAEAt/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4ToFxGEmP4VxgUAAegXBl6E 6BdghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/k9KAwBRSgMAbygAAQCn8AEA AAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRo AWCEmP5PSgMAUUoDAG8oAAEA2PABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oEAFFKBABvKAABAG8AAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgH YISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagMBl6EqAxg hJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KAwBRSgMAbygAAQCn8AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCE mP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oEAFFKBABvKAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY /k9KAwBRSgMAbygAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgMAUUoDAG8oAAEA2PABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+ T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E CAcRhJj+FcYFAAEIBwZehAgHYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4So DBGEmP4VxgUAAagMBl6EqAxghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9K AwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgS EYSY/hXGBQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oE AFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcR hJj+FcYFAAHoFwZehOgXYISY/k9KAwBRSgMAbygAAQCn8BUAAAAXEAAAAAAA AAAAAAAAAAAAAAAAAAYYAJUPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP41CAFv KAABAC0AAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgMAUUoDAG8o AAEAp/ABAAAAF5AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUA AUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABRSgQAbygA AQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB 4BAGXoTgEGCEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgMAUUoDAG8oAAEA p/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgB Bl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBABRSgQAbygAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcG XoQIB2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBvKAABALfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZe hKgMYISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgMAUUoDAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6E SBJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KBABRSgQAbygAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoTo F2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oDAFFKAwBvKAABANjwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgE YISY/k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgMAUUoDAG8oAAEAp/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2Alg hJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/k9KBABRSgQAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CE mP5PSgMAUUoDAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY /k9KBABRSgQAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgMAUUoDAG8oAAEAp/AXAAAAAmoR UAAAAAAAAAAAAAAAAG8NWQsAAAAAAAAAAAAAAACSWCAbAAAAAAAAAAAAAAAA VW+WfwAAAAAAAAAAAAAAAOpBVXMAAAAAAAAAAAAAAACXSIBdAAAAAAAAAAAA AAAAG1xDOgAAAAAAAAAAAAAAAA4LzBAAAAAAAAAAAAAAAACpedB8AAAAAAAA AAAAAAAAYXIAQAAAAAAAAAAAAAAAAAxMYjAAAAAAAAAAAAAAAAAoVMoqAAAA AAAAAAAAAAAAYxUeNAAAAAAAAAAAAAAAAIloxy0AAAAAAAAAAAAAAACHHVlb AAAAAAAAAAAAAAAA1wvhKAAAAAAAAAAAAAAAAK8ncycAAAAAAAAAAAAAAAB2 YyFIAAAAAAAAAAAAAAAAJ3PLdwAAAAAAAAAAAAAAABMghBUAAAAAAAAAAAAA AAB5NilZAAAAAAAAAAAAAAAAQVtyQgAAAAAAAAAAAAAAAF8M4T4AAAAAAAAA AAAAAAD///////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////FwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/QAGAAQDEBgAAxAYAAADqkAEBAAEAxAYAAAAAAACi BgAAAAAAAAIQAAAAAAAAALAQAACAAAAIAEAAAAcAAABHFpABAAACAgYDBQQF AgMEh3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAA AAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAAAAA AIAIAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAAOwaQAQIABQAAAAAAAAAA AAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAA PzWQAQAAAgcDCQICBQIEBId6AAAAAACACAAAAAAAAAD/AAAAAAAAAEMAbwB1 AHIAaQBlAHIAIABOAGUAdwAAAEMikAEAAAAAAAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAQAAAAAAAABBAG4AdABpAHEAdQBlACAATwBsAGkAdgBlAAAAQRaQ AQAAAgQGAgUDBQMDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEIAbwBvAGsA IABBAG4AdABpAHEAdQBhAAAAIgAEAHEIiBgA8MQCAACpAQAAAAAbTGpm2txq BgAAAAAKABUAAABpAgAAwg0AAAEABwAAAAQAAxAdAAAAAAAAAAAAAAABAAEA AAABAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADcCtAC0ALQAgYESMAAAAAAAAAAAAAAAAAAA5RAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIGAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAAEQBGAHIA6QBkAOkA cgBpAGMAIAAgAEIARQBSAFQATwBOACAAAAAAAAAAAgBDAEIABABHAEIATQBB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAA AAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAARAAAAAQAA AJAAAAACAAAAmAAAAAMAAAC0AAAABAAAAMAAAAAFAAAAzAAAAAYAAADYAAAA BwAAAOQAAAAIAAAA+AAAAAkAAAAIAQAAEgAAABQBAAAKAAAAMAEAAAwAAAA8 AQAADQAAAEgBAAAOAAAAVAEAAA8AAABcAQAAEAAAAGQBAAATAAAAbAEAAAIA AADkBAAAHgAAABIAAABGculk6XJpYyAgQkVSVE9OIABkAB4AAAABAAAAAHLp ZB4AAAADAAAAQ0IAZB4AAAABAAAAAEIAZB4AAAABAAAAAEIAZB4AAAALAAAA Tm9ybWFsLmRvdABFHgAAAAUAAABHQk1BAGwuZB4AAAADAAAAMTAAQR4AAAAT AAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAL4E7wIAAABAAAAAALqST6hv wgFAAAAAACyMTOZ9wgEDAAAAAQAAAAMAAABpAgAAAwAAAMINAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAA AAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX CAArLPmuRAEAAAABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAA AIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAA FgAAALwAAAANAAAAxAAAAAwAAADiAAAAAgAAAOQEAAAeAAAACgAAAENCX0Zh bWlseQBlAAMAAAAdAAAAAwAAAAcAAAADAAAA5RAAAAMAAAAxFQgACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABIAAABGculk6XJp YyAgQkVSVE9OIAAMEAAAAgAAAB4AAAAGAAAAVGl0cmUAAwAAAAEAAABEAQAA BAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAAAAMAAACyAAAAAgAAAAIAAAAK AAAAX1BJRF9HVUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAA TgAAAHsANgAwADMAQwAyADAAMQBCAC0ARAA0AEEARgAtADQAQwA2ADQALQBB ADYARgBEAC0AMAA3ADAAMgBEADAARgA2ADUARABFAEEAfQAAAAAAQQAAAIgA AAAGAAAAAwAAAAMAfgADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKAAA AG0AYQBpAGwAdABvADoARgByAGUAZABlAHIAaQBjAC4AQgBlAHIAdABvAG4A QABlAHMAaQBsAC4AdQBuAGkAdgAuAG0AcgBzAC4AZgByAAAAHwAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAP AAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAAGQAAABoA AAAbAAAAHAAAAB0AAAD+////HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAA ACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8 AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAA/v///0QAAABFAAAARgAAAEcA AABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAA AP7////9////VQAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA AAAAwAAAAAAAAEYAAAAAAP8c3Y97wgGw9dta5n3CAVcAAACAAAAAAAAAAEQA YQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAAAAQAAAAAAAAMQBUAGEAYgBs AGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAeAAAA6EgAAAAAAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAGgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAeKgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLAAAA ABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAA AE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAACw9dta5n3CAbD121rmfcIBAAAAAAAAAAAAAAAAAQAAAP7/ //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAERv Y3VtZW50IE1pY3Jvc29mdCBXb3JkAAoAAABNU1dvcmREb2MAEAAAAFdvcmQu RG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --------------CC08D6435A2FC1849BCD8E57-- From owner-linux-xfs@oss.sgi.com Wed Oct 30 05:40:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 05:40:52 -0800 (PST) Received: from cli_exch_one.complexlit.com (exchange.complexlit.com [65.196.35.30]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UDenuR005261 for ; Wed, 30 Oct 2002 05:40:50 -0800 content-class: urn:content-classes:message Subject: Red Hat 8.0 + 1.2pre2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 30 Oct 2002 08:41:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <5A2E4FE5C3D6544D94403072129E30D92B8938@cli_exch_one.complexlit.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Share suddenly empty Thread-Index: AcJ6208cqmks0UPRRAa844JJl1Cu4QFPivlQ From: "Brian Gulizia" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9UDeouR005262 X-archive-position: 1385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.gulizia@complexlit.com Precedence: bulk X-list: linux-xfs Hello, I'm about to load red hat 8.0 and xfs 1.2pre1 for testing on a system that has all of a sudden become available to me thanks to the problems I've had lately. I hate to ask, but in order to get up to 1.2pre2 from pre1 the only thing I need to do is load the new kernel rpm for pre2, right? Is there anything else I need to do? Will the rpm automatically put a new entry in grub? Thanks, Brian Gulizia From owner-linux-xfs@oss.sgi.com Wed Oct 30 06:24:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 06:24:17 -0800 (PST) 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 g9UEOCuR006410 for ; Wed, 30 Oct 2002 06:24:13 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 4D44DAC4E; Wed, 30 Oct 2002 15:19:06 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 31E27190BD; Wed, 30 Oct 2002 15:19:05 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id C483E30881D; Wed, 30 Oct 2002 15:24:47 +0100 (CET) Message-ID: <3DBFEBAF.E2364988@ch.sauter-bc.com> Date: Wed, 30 Oct 2002 15:24:47 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Brian Gulizia Cc: linux-xfs@oss.sgi.com Subject: Re: Red Hat 8.0 + 1.2pre2 References: <5A2E4FE5C3D6544D94403072129E30D92B8938@cli_exch_one.complexlit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1386 X-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 Brian Gulizia schrieb: > > Hello, > > I'm about to load red hat 8.0 and xfs 1.2pre1 for testing on a system > that has all of a sudden become available to me thanks to the problems I've > had lately. I hate to ask, but in order to get up to 1.2pre2 from > pre1 the only thing I need to do is load the new kernel rpm for pre2, Maybe there are newer xfstools available too, don't know. > right? Is there anything else I need to do? Will the rpm > automatically put a new entry in grub? Yes, it will. Simon > > Thanks, > > Brian Gulizia From owner-linux-xfs@oss.sgi.com Wed Oct 30 07:00:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 07:00:47 -0800 (PST) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UF0duR007162 for ; Wed, 30 Oct 2002 07:00:42 -0800 Received: from willy by www.linux.org.uk with local (Exim 3.33 #5) id 186uLM-0007lF-00 for linux-xfs@oss.sgi.com; Wed, 30 Oct 2002 15:01:16 +0000 Date: Wed, 30 Oct 2002 15:01:16 +0000 From: Matthew Wilcox To: linux-xfs@oss.sgi.com Subject: FW: unlink deadlock Message-ID: <20021030150116.X27461@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 1387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: linux-xfs hp's mail servers & sgi's don't seem to get along. can someone look into it? ----- Forwarded message from "GOBEILLE,BOB (HP-FtCollins,ex1)" ----- Envelope-to: willy@www.uk.linux.org Delivery-date: Wed, 30 Oct 2002 14:58:40 +0000 From: "GOBEILLE,BOB (HP-FtCollins,ex1)" To: "WILCOX,MATTHEW (HP-FtCollins,unix1)" Subject: FW: unlink deadlock Date: Tue, 29 Oct 2002 14:09:48 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Resent-From: willy@ldl.fc.hp.com Resent-Date: Wed, 30 Oct 2002 07:58:32 -0700 Resent-To: willy@www.uk.linux.org Resent-Message-Id: <20021030145832.CD0AE461A@ldl.fc.hp.com> Willy, This message I sent to linux-xfs never got there. I also sent it to hch and never received a reply. Either I'm being ignored as being too ignorant or my email isn't reaching it's destination. Would you do me a favor, and take my original email below, edit it however you see fit and send it to linux-xfs? I just feel like we have some useful data here if it could get to the right eyes. Thanks, Bob -----Original Message----- From: GOBEILLE,BOB (HP-FtCollins,ex1) Sent: Saturday, October 26, 2002 5:46 PM To: 'linux-xfs@oss.sgi.com' Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c This problem sounds somewhat similiar to an intermittant problem we are seeing on a 2.4.18 cluster of dual cpu IA-64 nodes. Two processes on each node are writing (different) checkpoint files to the same directory on an XFS RAID 0 array and sometimes ending up in a D state and locking the entire filesystem (can't even do an ls). Each process is writing a 155 MB checkpoint file A then a 155 MB checkpoint file B then unlinking A and writing a new A, then unlinks B ... Were trying to reproduce the problem with a single process writing two large files (1MB to 3,000MB) and unlinking them over and over again but haven't been successful yet. I haven't tried your patches because I don't understand them. Do you think your patches might address this problem? We are also trying to reproduce the problem on the 32 node cluster with a kdb instrumented 2.4.18. Here is some data (truncated to the D state processes) on the state of one node where two processes (nwchem.0) are doing an unlink (of different files) and getting in a D state locking the filesystem. The other commands (touch, ls, ...) were then done to show that the fs is really locked up. >ps -eo pid,user,fname,tmout,f,wchan PID USER COMMAND TMOUT F WCHAN 1744 edo nwchem.o - 000 down 6623 hpsupt bash - 000 down 7308 root updatedb - 100 down 7700 root touch - 000 down 7757 root ls - 000 down 8254 hpsupt bash - 000 down 1745 edo nwchem.o - 000 down 8429 hpsupt bash - 000 down >top -b -n 1 1:02pm up 1 day, 57 min, 4 users, load average: 8.99, 8.97, 8.91 96 processes: 90 sleeping, 1 running, 5 zombie, 0 stopped CPU0 states: 1.1% user, 3.7% system, 0.0% nice, 95.1% idle CPU1 states: 0.0% user, 0.2% system, 0.0% nice, 99.8% idle Mem: 12365920K av, 1739696K used, 10626224K free, 0K shrd, 59056K buff Swap: 12287920K av, 3792K used, 12284128K free 969888K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1744 edo 12 0 1983M 689M 559M D 0.0 1.4 80:01 nwchem.ok 6623 hpsupt 12 0 5376 5376 3888 D 0.0 0.0 0:00 bash 7308 root 20 19 2352 2352 1808 D N 0.0 0.0 0:00 updatedb 7700 root 12 0 2144 2144 1792 D 0.0 0.0 0:00 touch 7757 root 12 0 2560 2560 2080 D 0.0 0.0 0:00 ls 7890 hpsupt 12 0 5360 5360 3872 D 0.0 0.0 0:00 bash 8254 hpsupt 12 0 5360 5360 3872 D 0.0 0.0 0:00 bash 1745 edo 12 0 1982M 687M 558M D 0.0 1.4 80:07 nwchem.ok 8429 hpsupt 12 0 5360 5360 3872 D 0.0 0.0 0:00 bash 99 active task structs found >> # ## 0xe00000028b6e0000 19911 1744 1 2 0 - nwchem.ok # >> deftask 0xe00000028b6e0000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe00000028b6e0000 (nwchem.ok) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 sys_unlink+332 [0xe0000000044ee28c] ================================================================ >> # ## 0xe0000040f1188000 19911 1745 1 2 0x8000 - nwchem.ok # >> deftask 0xe0000040f1188000 Default task is 0xe0000040f1188000 >> trace -f | more ================================================================ STACK TRACE FOR TASK: 0xe0000040f1188000 (nwchem.ok) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 pagebuf_lock+140 [0xe0000000046de4ec] 3 _pagebuf_find_lockable_buffer+540 [0xe0000000046ddcfc] 4 _pagebuf_get_lockable_buffer+140 [0xe0000000046de12c] 5 pagebuf_get+60 [0xe0000000046d50bc] 6 xfs_trans_get_buf+508 [0xe0000000046bac1c] 7 xfs_btree_get_bufs+156 [0xe000000004657f1c] 8 xfs_alloc_newroot+204 [0xe00000000462bdcc] 9 xfs_alloc_insrec+124 [0xe00000000462a23c] 10 xfs_alloc_insert+252 [0xe00000000462e2fc] 11 xfs_free_ag_extent+2316 [0xe000000004625b4c] 12 xfs_alloc_fix_freelist+1740 [0xe00000000462668c] 13 xfs_free_extent+332 [0xe00000000462816c] 14 xfs_bmap_finish+508 [0xe000000004647abc] 15 xfs_itruncate_finish+700 [0xe0000000046937fc] 16 xfs_inactive+1468 [0xe0000000046c6fdc] 17 vn_put+380 [0xe0000000046f0dbc] 18 linvfs_put_inode+44 [0xe0000000046edf2c] 19 iput+268 [0xe00000000450658c] 20 d_delete+368 [0xe000000004500d10] 21 vfs_unlink+1132 [0xe0000000044ee0ac] 22 sys_unlink+524 [0xe0000000044ee34c] ================================================================ >> # ## 0xe00000409f888000 500 6623 1 2 0 - bash # >> deftask 0xe00000409f888000 Default task is 0xe00000409f888000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe00000409f888000 (bash) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 real_lookup+76 [0xe0000000044e7f8c] 3 link_path_walk+4572 [0xe0000000044e981c] 4 path_walk+44 [0xe0000000044e9f6c] 5 __user_walk+124 [0xe0000000044eb01c] 6 sys_newlstat+60 [0xe0000000044e10dc] ================================================================ >> # ## 0xe000000270578000 0 7308 7305 2 0x100 - updatedb # >> deftask 0xe000000270578000 Default task is 0xe000000270578000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe000000270578000 (updatedb) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 vfs_readdir+172 [0xe0000000044f4aec] 3 sys_getdents64+156 [0xe0000000044f5a3c] ================================================================ >> # ## 0xe0000001ac3e0000 0 7700 1 2 0 - touch # >> deftask 0xe0000001ac3e0000 Default task is 0xe0000001ac3e0000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe0000001ac3e0000 (touch) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 open_namei+572 [0xe0000000044eb5bc] 3 filp_open+92 [0xe0000000044c9dfc] 4 sys_open+156 [0xe0000000044ca81c] ================================================================ >> # ## 0xe0000002ab978000 0 7757 1 2 0 - ls # >> deftask 0xe0000001ac3e0000 Default task is 0xe0000001ac3e0000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe0000001ac3e0000 (touch) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 open_namei+572 [0xe0000000044eb5bc] 3 filp_open+92 [0xe0000000044c9dfc] 4 sys_open+156 [0xe0000000044ca81c] ================================================================ >> # ## 0xe000000196798000 500 7890 1 2 0 - bash # >> deftask 0xe000000196798000 Default task is 0xe000000196798000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe000000196798000 (bash) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 real_lookup+76 [0xe0000000044e7f8c] 3 link_path_walk+4572 [0xe0000000044e981c] 4 path_walk+44 [0xe0000000044e9f6c] 5 __user_walk+124 [0xe0000000044eb01c] 6 sys_newlstat+60 [0xe0000000044e10dc] ================================================================ >> # ## 0xe0000001940d8000 500 8254 1 2 0 - bash # >> deftask 0xe0000001940d8000 Default task is 0xe0000001940d8000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe0000001940d8000 (bash) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 real_lookup+76 [0xe0000000044e7f8c] 3 link_path_walk+4572 [0xe0000000044e981c] 4 path_walk+44 [0xe0000000044e9f6c] 5 __user_walk+124 [0xe0000000044eb01c] 6 sys_newlstat+60 [0xe0000000044e10dc] ================================================================ >> # ## 0xe000000191e38000 500 8429 1 2 0 - bash # >> deftask 0xe000000191e38000 Default task is 0xe000000191e38000 >> trace -f ================================================================ STACK TRACE FOR TASK: 0xe000000191e38000 (bash) 0 schedule+3724 [0xe00000000446d06c] 1 __down+524 [0xe0000000044246ec] 2 real_lookup+76 [0xe0000000044e7f8c] 3 link_path_walk+4572 [0xe0000000044e981c] 4 path_walk+44 [0xe0000000044e9f6c] 5 __user_walk+124 [0xe0000000044eb01c] 6 sys_newlstat+60 [0xe0000000044e10dc] ================================================================ >> ----- End forwarded message ----- -- Revolutions do not require corporate support. From owner-linux-xfs@oss.sgi.com Wed Oct 30 07:03:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 07:03:39 -0800 (PST) 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 g9UF3buR007620 for ; Wed, 30 Oct 2002 07:03:37 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA91973 for ; Wed, 30 Oct 2002 09:04:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA12315 for ; Wed, 30 Oct 2002 09:04:09 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9UF41v15147; Wed, 30 Oct 2002 09:04:01 -0600 Message-Id: <200210301504.g9UF41v15147@jen.americas.sgi.com> Date: Wed, 30 Oct 2002 09:04:01 -0600 Subject: TAKE - fix loop termination logic in xfs_sync To: linux-xfs@oss.sgi.com X-archive-position: 1388 X-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 quite sure why I changed it the way I did a long time ago, but the loop in xfs which flushes inodes to disk could well skip the last inode. Thanks to ASANO Masahiro for pointing this out. Date: Wed Oct 30 07:02:08 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131490a linux/fs/xfs/xfs_vfsops.c - 1.396 - fix loop termination logic in xfs_sync From owner-linux-xfs@oss.sgi.com Wed Oct 30 08:21:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 08:21:24 -0800 (PST) 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 g9UGLIuR013769 for ; Wed, 30 Oct 2002 08:21:19 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186vbP-0007oe-00; Wed, 30 Oct 2002 16:21:55 +0000 Date: Wed, 30 Oct 2002 16:21:55 +0000 From: Christoph Hellwig To: Matthew Wilcox Cc: linux-xfs@oss.sgi.com, bob.gobeille@hp.com Subject: Re: FW: unlink deadlock Message-ID: <20021030162155.A29948@infradead.org> References: <20021030150116.X27461@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021030150116.X27461@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Wed, Oct 30, 2002 at 03:01:16PM +0000 X-archive-position: 1389 X-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 > seeing on a 2.4.18 cluster of dual cpu IA-64 nodes. Two processes on each > node are writing (different) checkpoint files to the same directory on an > XFS RAID 0 array and sometimes ending up in a D state and locking the entire > filesystem (can't even do an ls). Each process is writing a 155 MB > checkpoint file A then a 155 MB checkpoint file B then unlinking A and > writing a new A, then unlinks B ... Were trying to reproduce the problem > with a single process writing two large files (1MB to 3,000MB) and unlinking > them over and over again but haven't been successful yet. 2.4.18 is pretty old and some of the functions in your trace don't exist anymore in that form. Any chance you could reproduce it with a current tree? From owner-linux-xfs@oss.sgi.com Wed Oct 30 08:30:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 08:30:14 -0800 (PST) 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 g9UGUAuR014270 for ; Wed, 30 Oct 2002 08:30:11 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA64867; Wed, 30 Oct 2002 10:30:43 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA24440; Wed, 30 Oct 2002 10:30:39 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9UGUVN21833; Wed, 30 Oct 2002 10:30:31 -0600 Subject: Re: FW: unlink deadlock From: Steve Lord To: Christoph Hellwig Cc: Matthew Wilcox , linux-xfs@oss.sgi.com, bob.gobeille@hp.com In-Reply-To: <20021030162155.A29948@infradead.org> References: <20021030150116.X27461@parcelfarce.linux.theplanet.co.uk> <20021030162155.A29948@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Oct 2002 10:30:31 -0600 Message-Id: <1035995431.18029.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1390 X-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-30 at 10:21, Christoph Hellwig wrote: > > seeing on a 2.4.18 cluster of dual cpu IA-64 nodes. Two processes on each > > node are writing (different) checkpoint files to the same directory on an > > XFS RAID 0 array and sometimes ending up in a D state and locking the entire > > filesystem (can't even do an ls). Each process is writing a 155 MB > > checkpoint file A then a 155 MB checkpoint file B then unlinking A and > > writing a new A, then unlinks B ... Were trying to reproduce the problem > > with a single process writing two large files (1MB to 3,000MB) and unlinking > > them over and over again but haven't been successful yet. > > 2.4.18 is pretty old and some of the functions in your trace don't exist > anymore in that form. Any chance you could reproduce it with a current tree? > Christoph, sorry, I responded off list and sent them the last two pagebuf changes to try in their tree. I suspect they were being bitten by at least one of them. 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 30 08:40:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 08:40:06 -0800 (PST) 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 g9UGe3uR014767 for ; Wed, 30 Oct 2002 08:40:03 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186vtV-00083S-00; Wed, 30 Oct 2002 16:40:37 +0000 Date: Wed, 30 Oct 2002 16:40:37 +0000 From: Christoph Hellwig To: Simon Matter Cc: Eric Sandeen , ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: patch howto??? Message-ID: <20021030164037.A30936@infradead.org> References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> <20021028220654.B31860@infradead.org> <3DBE369D.DEAA0608@ch.sauter-bc.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: <3DBE369D.DEAA0608@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Tue, Oct 29, 2002 at 08:19:57AM +0100 X-archive-position: 1391 X-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 Tue, Oct 29, 2002 at 08:19:57AM +0100, Simon Matter wrote: > I've installed the kernels mentioned above on several RH 7.2 servers. It > has worked - like before - very well. The only problem I had was when > upgrading my laptop. The PCMCIA stuff seems broken somehow and unloading > kernel modules of PCMCIA devices just crashes the box. I'm sure the > problem is that those new kernels were built on RedHat 8.0 which is > quite different from 7.x. I then tried to rebuild from source RPM on > RedHat 7.2. Building i386 and i586 packages went fine but i686 didn't. > I'm happy anyway and thanks for the great product! The problem is that these kernel are built with gcc 3.2 - if you build the pcmcia modules (or any other kernel module) with gcc 2.96 you'll get struct mismatches. OTOH I'm not even sure whether there are external pcmcia module on RH.. When I tried to build those kernel on my RH7.3 box I got internal compiler error, but I have to admit I've not updated to the latest gcc eratta :) Maybe we should provide a gcc 2.96 built version for the RH7.x usesers, too.. From owner-linux-xfs@oss.sgi.com Wed Oct 30 08:58:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 08:58:38 -0800 (PST) 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 g9UGwZuR015742 for ; Wed, 30 Oct 2002 08:58:36 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA80495 for ; Wed, 30 Oct 2002 10:59:08 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA90540 for ; Wed, 30 Oct 2002 10:59:08 -0600 (CST) Received: from rose.americas.sgi.com (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9UGxxkq021629 for ; Wed, 30 Oct 2002 10:59:59 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.5/8.12.5/Submit) id g9UGxx2p021627 for linux-xfs@oss.sgi.com; Wed, 30 Oct 2002 10:59:59 -0600 Date: Wed, 30 Oct 2002 10:59:59 -0600 From: Rusell Cattelan Message-Id: <200210301659.g9UGxx2p021627@rose.americas.sgi.com> Subject: TAKE - comment width change :-) X-archive-position: 1392 X-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@rose.americas.sgi.com Precedence: bulk X-list: linux-xfs narrow down comment Date: Wed Oct 30 08:58:29 PST 2002 Workarea: rose.americas.sgi.com:/usr/src/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131504a linux/fs/xfs/linux/xfs_aops.c - 1.12 - got a little carried away with comment width. From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:10:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:10:16 -0800 (PST) Received: from web11804.mail.yahoo.com (web11804.mail.yahoo.com [216.136.172.158]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UIABuR019919 for ; Wed, 30 Oct 2002 10:10:11 -0800 Message-ID: <20021030181050.54638.qmail@web11804.mail.yahoo.com> Received: from [156.153.255.196] by web11804.mail.yahoo.com via HTTP; Wed, 30 Oct 2002 10:10:50 PST Date: Wed, 30 Oct 2002 10:10:50 -0800 (PST) From: P-niiice Subject: HP email test for Bob Gobeille - please reply. To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 289 X-archive-position: 1393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pniiice@yahoo.com Precedence: bulk X-list: linux-xfs Please reply. I''m troubleshooting an email delivery issue for Bob. If necessary, Bob will confirm this. Thanks, Patrick Ballenger MCX Admin Volt Services @HP. --------------------------------- Do you Yahoo!? HotJobs - Search new jobs daily now [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:13:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:13:47 -0800 (PST) Received: from imf13bis.bellsouth.net (mail313.mail.bellsouth.net [205.152.58.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UIDiuR020318 for ; Wed, 30 Oct 2002 10:13:44 -0800 Received: from TAZ2 ([66.156.0.123]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021030181602.QOWE14849.imf13bis.bellsouth.net@TAZ2>; Wed, 30 Oct 2002 13:16:02 -0500 Date: Wed, 30 Oct 2002 13:14:17 -0500 From: Greg Freemyer Subject: re: patch howto??? To: , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021030181602.QOWE14849.imf13bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9UIDjuR020338 X-archive-position: 1394 X-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 >> I would like to update these systems to 2.4.18-17.7, and need to merge >> in the XFS bits. Not really related to your question, but the linux-ha team is having major problems with this kernel. It seems that the process scheduling is unreliable and that they can get deadtimes on their communications heartbeats in the 10's of seconds. FYI: the heartbeat app is set to run at the highest realtime priority, so having to wait so long definitely indicates a kernel bug. They have numerous users reporting the problem and it is unique to that specific kernel. I for one am avoiding it. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:21:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:21:13 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UIL7uR020917 for ; Wed, 30 Oct 2002 10:21:07 -0800 Received: (qmail 30087 invoked by uid 500); 30 Oct 2002 18:21:18 -0000 Subject: Can anyone give me some diagnosis? From: Austin Gonyou To: linux-xfs@oss.sgi.com Cc: andrea@suse.de Content-Type: multipart/mixed; boundary="=-7eBWIX74cuAedFUTK985" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Oct 2002 12:21:18 -0600 Message-Id: <1036002078.30049.4.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1395 X-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 --=-7eBWIX74cuAedFUTK985 Content-Type: text/plain Content-Transfer-Encoding: 7bit I've recently got a message in dmesg about detecting possible stack overflow. I checked my kernel log, and found a lot of good info. It is attatched. I'm not sure if this is a pagebuf bug or what, but any help would be appreciated. I'm using 2.4.19-aa1. Austin --=-7eBWIX74cuAedFUTK985 Content-Description: Error output from potential stack overflow. Content-Disposition: inline; filename=DB-potential-ooops.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Oct 30 00:28:19 Infdb2 kernel: Detected potential for stack overflows, stac= k left: 884 bytes Oct 30 00:28:19 Infdb2 kernel: d6908a18 c02a7e40 00000374 00000003 c7b98800= e348c020 8d041cac 2902040a Oct 30 00:28:19 Infdb2 kernel: c010d248 c7b98800 d6908000 00000000 e= 348c020 8d041cac 2902040a c031a250 Oct 30 00:28:19 Infdb2 kernel: 052b0018 0b030018 ffffff12 c028e89a 0= 0000010 00000216 05401100 0a9e005f Oct 30 00:28:19 Infdb2 kernel: Call Trace: [call_do_IRQ+5/13] [ipt_do_ta= ble+170/1008] [ipt_local_hook+119/208] [ip_local_deliver_finish+0/304] [nf_= iterate+46/128] Oct 30 00:28:19 Infdb2 kernel: Call Trace: [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [ip_local_deliver_finish+0/304] [ip_local_= deliver_finish+0/304] [nf_hook_slow+207/384] [ip_local_deliver_finish+0/304= ] [ip_local_deliver+379/400] [ip_local_deliver_finish+0/304] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [ip_rcv_finish+388/447] [ip_rcv_finish+0/4= 47] [nf_hook_slow+207/384] [ip_rcv_finish+0/447] [nf_hook_slow+262/384] [ne= tif_rx+161/272] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [ip_rcv+858/928] [ip_rcv_finish+0/447] [ne= t_rx_action+379/656] [tg3_interrupt+68/112] [do_softirq+123/224] [do_IRQ+25= 4/272] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [call_do_IRQ+5/13] [__make_request+1470/15= 04] [avl_insert+219/256] [generic_make_request+266/288] [_pagebuf_page_io+5= 91/688] [avl_lookup_next+69/160] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [_page_buf_page_apply+280/304] [pagebuf_se= gment_apply+128/224] [pagebuf_iorequest+270/368] [_page_buf_page_apply+0/30= 4] [add_to_page_cache_unique+130/144] [_pagebuf_lookup_pages+561/944] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [_pagebuf_lookup_pages+720/944] [pagebuf_i= ostart+134/160] [pagebuf_get+170/240] [xfs_trans_read_buf+465/800] [xfs_btree_read_bufs+92/128] [xfs_alloc_lookup+228/832] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [xfs_alloc_ag_vextent_near+93/2896] [xfs_a= lloc_ag_vextent+54/240] [xfs_alloc_vextent+807/960] [xfs_bmap_alloc+5764/66= 24] [xfs_bmapi+2038/4624] [xfs_dir2_grow_inode+209/960] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [xfs_dir2_sf_to_block+174/1600] [tg3_start= _xmit_4gbug+380/992] [xfs_bmbt_get_state+37/48] [xfs_bmap_do_search_extents= +840/896] [xfs_bmap_search_extents+72/80] [xfs_bmapi+843/4624] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [nf_hook_slow+262/384] [avl_lookup+88/112]= [avl_insert+219/256] [locate_hd_struct+39/112] [req_new_io+73/96] [__make_request+1232/1504] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [avl_remove+201/224] [generic_make_request= +266/288] [avl_lookup_next+69/160] [_pagebuf_find_lockable_buffer+495/560] = [megaIssueCmd+271/656] [mega_runpendq+35/64] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [_pagebuf_get_object+62/320] [__find_lock_= page+32/48] [_pagebuf_lookup_pages+720/944] [kmem_zone_zalloc+61/208] [xfs_= buf_item_init+58/160] [avl_delete+114/128] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [_pagebuf_free_lockable_buffer+44/64] [_pa= gebuf_free_object+234/272] [vn_revalidate+55/272] [xfs_trans_init+930/6640]= [xfs_iget_core+1579/1600] [kmem_cache_zalloc+104/304] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [kmem_zone_zalloc+61/208] [xfs_inode_item_= init+23/112] [xfs_trans_iget+215/288] [xfs_dir2_sf_addname+198/304] [xfs_di= r2_createname+205/304] [xfs_create+1146/2704] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [xfs_bmbt_get_state+37/48] [linvfs_common_= cr+377/688] [xfs_bmap_search_extents+72/80] [xfs_acl_iaccess+45/144] [xfs_a= cl_iaccess+45/144] [xfs_acl_iaccess+45/144] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [xfs_dir2_lookup+178/320] [lru_cache_add+1= 01/112] [filemap_nopage+214/560] [filemap_nopage+259/560] [filemap_nopage+0= /560] [do_no_page+172/928] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [linvfs_create+24/32] [vfs_create+284/384]= [lookup_hash+74/208] [open_namei+371/1728] [dentry_open+230/432] [dput+28/= 272] Oct 30 00:28:19 Infdb2 kernel: [] [] [] [] [] [] Oct 30 00:28:19 Infdb2 kernel: [filp_open+54/96] [sys_open+52/160] [syste= m_call+51/56] Oct 30 00:28:19 Infdb2 kernel: [] [] [] --=-7eBWIX74cuAedFUTK985-- From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:48:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:48:48 -0800 (PST) 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 g9UImjuR023412 for ; Wed, 30 Oct 2002 10:48:45 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186xu6-0000fX-00; Wed, 30 Oct 2002 18:49:22 +0000 Date: Wed, 30 Oct 2002 18:49:22 +0000 From: Christoph Hellwig To: Austin Gonyou Cc: linux-xfs@oss.sgi.com, andrea@suse.de Subject: Re: Can anyone give me some diagnosis? Message-ID: <20021030184922.A2568@infradead.org> References: <1036002078.30049.4.camel@ubergeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1036002078.30049.4.camel@ubergeek>; from austin@coremetrics.com on Wed, Oct 30, 2002 at 12:21:18PM -0600 X-archive-position: 1396 X-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 30, 2002 at 12:21:18PM -0600, Austin Gonyou wrote: > I've recently got a message in dmesg about detecting possible stack > overflow. > > I checked my kernel log, and found a lot of good info. It is attatched. > I'm not sure if this is a pagebuf bug or what, but any help would be > appreciated. I'm using 2.4.19-aa1. 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a resent XFS tree (like the ones in 2.4.20pre5aa and following). Also make sure you don't use a broken stack-eating storage driver like the qlogic ones. From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:50:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:50:52 -0800 (PST) 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 g9UIonuR023819 for ; Wed, 30 Oct 2002 10:50:49 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA45055 for ; Wed, 30 Oct 2002 12:51:22 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA12946 for ; Wed, 30 Oct 2002 12:51:22 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9UIpDO02922; Wed, 30 Oct 2002 12:51:13 -0600 Message-Id: <200210301851.g9UIpDO02922@jen.americas.sgi.com> Date: Wed, 30 Oct 2002 12:51:13 -0600 Subject: TAKE - xfs io path code reorg To: linux-xfs@oss.sgi.com X-archive-position: 1397 X-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 break out the allocator specific parts of the xfs I/O path into a separate file, xfs_iomap.c out of xfs_lrw.c. Remove some parts of the code which were not doing anything for us. This is step one in some major reorgs of this code. Date: Wed Oct 30 10:50:40 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131524a linux/fs/xfs/linux/xfs_iomap.c - 1.1 - move allocator based calls here from xfs_lrw.c linux/fs/xfs/linux/xfs_lrw.c - 1.175 - move allocator based calls from here to xfs_iomap.c linux/fs/xfs/linux/Makefile - 1.66 - add xfs_iomap.c From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:51:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:51:53 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UIppuR024016 for ; Wed, 30 Oct 2002 10:51:51 -0800 Received: (qmail 30152 invoked by uid 500); 30 Oct 2002 18:51:48 -0000 Subject: Re: Can anyone give me some diagnosis? From: Austin Gonyou To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, andrea@suse.de In-Reply-To: <20021030184922.A2568@infradead.org> References: <20021030184922.A2568@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Oct 2002 12:51:48 -0600 Message-Id: <1036003908.30032.10.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1398 X-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 Wed, 2002-10-30 at 12:49, Christoph Hellwig wrote: [...] > 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a > resent > XFS tree (like the ones in 2.4.20pre5aa and following). Also make sure > you don't use a broken stack-eating storage driver like the qlogic ones. hrmm....that may be more difficult than it sounds...Is this error fatal? Is there something I can do to my 2.4.19-aa1, to just update the XFS code, so our codebase for our kernels can just be versioned? I would prefer to have our current 2.4.19 kernel, with updated xfs bits. TIA. Austin From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:56:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:56:47 -0800 (PST) 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 g9UIuiuR025205 for ; Wed, 30 Oct 2002 10:56:44 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 186y1q-0000k8-00; Wed, 30 Oct 2002 18:57:22 +0000 Date: Wed, 30 Oct 2002 18:57:21 +0000 From: Christoph Hellwig To: Austin Gonyou Cc: linux-xfs@oss.sgi.com, andrea@suse.de Subject: Re: Can anyone give me some diagnosis? Message-ID: <20021030185721.A2792@infradead.org> References: <20021030184922.A2568@infradead.org> <1036003908.30032.10.camel@ubergeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1036003908.30032.10.camel@ubergeek>; from austin@coremetrics.com on Wed, Oct 30, 2002 at 12:51:48PM -0600 X-archive-position: 1399 X-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 30, 2002 at 12:51:48PM -0600, Austin Gonyou wrote: > On Wed, 2002-10-30 at 12:49, Christoph Hellwig wrote: > [...] > > 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a > > resent > > XFS tree (like the ones in 2.4.20pre5aa and following). Also make sure > > you don't use a broken stack-eating storage driver like the qlogic ones. > > hrmm....that may be more difficult than it sounds...Is this error fatal? Yes, stackoverflows can cause random memory corruption. > Is there something I can do to my 2.4.19-aa1, to just update the XFS > code, so our codebase for our kernels can just be versioned? I would > prefer to have our current 2.4.19 kernel, with updated xfs bits. It's certainly possible, but you need to patch it in yourself :) Take 2.4.19-aa1, remove the 7* patches and try to fit in the XFS 1.2-pre2 or current CVS patches. There will be lots of rejects that need fixing. From owner-linux-xfs@oss.sgi.com Wed Oct 30 10:59:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 10:59:09 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UIx7uR025629 for ; Wed, 30 Oct 2002 10:59:07 -0800 Received: (qmail 30170 invoked by uid 500); 30 Oct 2002 18:58:58 -0000 Subject: Re: Can anyone give me some diagnosis? From: Austin Gonyou To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, andrea@suse.de In-Reply-To: <20021030185721.A2792@infradead.org> References: <20021030185721.A2792@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Oct 2002 12:58:58 -0600 Message-Id: <1036004338.30049.12.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1400 X-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 Wed, 2002-10-30 at 12:57, Christoph Hellwig wrote: > On Wed, Oct 30, 2002 at 12:51:48PM -0600, Austin Gonyou wrote: > > On Wed, 2002-10-30 at 12:49, Christoph Hellwig wrote: > > [...] > > > 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a > > > resent > > > XFS tree (like the ones in 2.4.20pre5aa and following). Also make > sure > > > you don't use a broken stack-eating storage driver like the qlogic > ones. > > > > hrmm....that may be more difficult than it sounds...Is this error > fatal? > > Yes, stackoverflows can cause random memory corruption. > > > Is there something I can do to my 2.4.19-aa1, to just update the XFS > > code, so our codebase for our kernels can just be versioned? I would > > prefer to have our current 2.4.19 kernel, with updated xfs bits. > > It's certainly possible, but you need to patch it in yourself :) Hot damn. I'll try it. > Take 2.4.19-aa1, remove the 7* patches and try to fit in the XFS > 1.2-pre2 > or current CVS patches. There will be lots of rejects that need fixing. NP, not like I haven't done that before! :) From owner-linux-xfs@oss.sgi.com Wed Oct 30 11:00:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 11:00:19 -0800 (PST) Received: from loback.org (a212-113-169-127.netcabo.pt [212.113.169.127] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UJ0AuR026044 for ; Wed, 30 Oct 2002 11:00:14 -0800 Received: from (212.113.168.94 [212.113.168.94]) by MailEnable Inbound Mail Agent with ESMTP; Tue, 22 Oct 2002 20:14:52 +0100 Message-ID: <7692200210222191452117@e-newsletter.pt> X-EM-Version: 5, 0, 0, 13 X-EM-Registration: #01B0530810E603002D00 From: "=?windows-1252?Q?Verlag_Dash=F6fer?=" To: linux-xfs@oss.sgi.com Subject: =?windows-1252?Q?:::_E-newsletters_Gr=E1tis_:::?= Date: Tue, 22 Oct 2002 20:14:52 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" X-archive-position: 1401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dashofer@mail.pt Precedence: bulk X-list: linux-xfs ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset="windows-1252" Caro(a) Senhor(a), Receba as nossas e-newsletters tem醫icas gratuitamente. Para subscrever, clique aqui! Sendo a Verlag Dash鰂er uma editora especializada em Manuais t閏nicos dirigidos a profissionais das mais diversas 醨eas, vem por este meio colocar sua inteira disposi玢o e de um modo gratuito, as suas e-newsletters tem醫icas. Estas e-newsletters s鉶 boletins informativos enviados, gratuitamente, para o seu email e que focam os seguintes temas: - Fiscalidade | - Contabilidade Exemplo de uma e-newsletter de fiscalidade. - Processamento Laboral - Recursos Humanos - Gest鉶 Empresas - Marketing e Vendas - E-Business - Higiene e Seguran鏰 no Trabalho - Qualidade | - Constru玢o - Dicas de Inform醫ica Para subscrever estas publica珲es peri骴icas, gratuitamente, basta efectuar um pequeno registo no nosso site. Muito Obrigado! ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable ::: E-newsletters Grátis :::

 
 
= =
Caro(a) Senhor(a),
= =
Receba as nossas e-newsletters tem=E1ticas gratuitament= e=2E Para subscrever, clique aqui!
 

Sendo a Verlag Dash=F6fer uma editora especializada em Ma= nuais t=E9cnicos dirigidos a profissionais das mais diversas =E1reas, vem p= or este meio colocar =E0 sua inteira disposi=E7=E3o e de um modo g= ratuito, as suas e-newsletters tem=E1ticas=2E

Estas e-newsletters s=E3o boletins informativos enviados,= gratuitamente, para o seu email e que focam os seguintes temas:

 - Fiscalidade | - Contabilidade

Exemplo de uma e-newsletter de fiscalidade=2E

 - Processamento Laboral

 - Recursos Humanos

 - Gest=E3o Empresas

 - Marketing e Vendas

 - E-Business

 - Higiene e Seguran=E7a no Trabalho

 - Qualidade | - Constru=E7=E3o

 - Dicas de Inform=E1tica

Para subscrever estas publica=E7=F5es peri=F3dicas, g= ratuitamente, basta efectuar um pequeno registo no nosso site=2E

Muito Obrigado!

 
------=_NextPart_84815C5ABAF209EF376268C8-- From owner-linux-xfs@oss.sgi.com Wed Oct 30 11:45:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 11:45:51 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UJjkuR026968 for ; Wed, 30 Oct 2002 11:45:46 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9UJkNA27887 for ; Wed, 30 Oct 2002 14:46:23 -0500 Message-ID: <3DC0371E.50908@ksimachine.com> Date: Wed, 30 Oct 2002 14:46:38 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Question about kernel update Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs I asked a couple of days ago about updating the kernel on a couple of RedHat 7.x systems to 2.4.18-17.7. This is the correct kernel version for the latest update on a RedHat 7.x system. I have downloaded all of the command RPM's and the needed kernel RPM's. When I test for dependencies it seems some other packages need to be updated. Here is a list of what is needed. libc.so.6(GLIBC_2.3) perl(strict) LATEXFILE /opt/cpg/bin/do-mgp It seems that the kernel on SGI's site have different dependencies that the RedHat 2.4.18-17.7 one. Does anyone know what RPM's I need and where I can get the correct ones? Also does anyone know if this is going to break anything else on the system? Simon responded on 10/29 that he has used this kernel on a RedHat 7.2 system. Maybe he knows what and where to get the needed RPM's. -- Joseph St.Clair From owner-linux-xfs@oss.sgi.com Wed Oct 30 11:51:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 11:51:40 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UJpbuR027439 for ; Wed, 30 Oct 2002 11:51:37 -0800 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel11.hp.com (Postfix) with ESMTP id 80B7F600E6B for ; Wed, 30 Oct 2002 11:52:11 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 7204EA9 for ; Wed, 30 Oct 2002 11:52:11 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 11:52:11 -0800 Message-ID: <079FD72E42C9D311B854009027650E6F0E7EB708@xatl02.atl.hp.com> From: "BALLENGER,PATRICK (HP-USA,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: HP email test - please ignore. Date: Wed, 30 Oct 2002 11:52:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2804D.D20427C0" X-archive-position: 1403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: partick.ballenger@hp.com Precedence: bulk X-list: linux-xfs This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2804D.D20427C0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2804D.D20427C0" ------_=_NextPart_001_01C2804D.D20427C0 Content-Type: text/plain; charset="iso-8859-1" Patrick Ballenger MCX Admin - Messaging support Volt Services @ HP ------_=_NextPart_001_01C2804D.D20427C0 Content-Type: text/html; charset="iso-8859-1" Blank

Patrick Ballenger
MCX Admin - Messaging support
Volt Services @ HP

       

 

 ------_=_NextPart_001_01C2804D.D20427C0-- ------_=_NextPart_000_01C2804D.D20427C0 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Blank Bkgrd.gif" Content-ID: <812345019@30102002-1fc1> R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02 898pGkgiYoCm6sq27iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9Jp JGmlYrPXGlfr/Yo/VW45e7amp2tou/lWxo/zX513z+Vt+1n/tiX2pxP4NUhy 2FM4xtjIUQAAOw== ------_=_NextPart_000_01C2804D.D20427C0-- From owner-linux-xfs@oss.sgi.com Wed Oct 30 12:01:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 12:01:14 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UK1AuR027998 for ; Wed, 30 Oct 2002 12:01:11 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9UK1nA28505 for ; Wed, 30 Oct 2002 15:01:49 -0500 Message-ID: <3DC03ABC.8040209@ksimachine.com> Date: Wed, 30 Oct 2002 15:02:04 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: patch howto??? References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> <20021028220654.B31860@infradead.org> <3DBE369D.DEAA0608@ch.sauter-bc.com> <20021030164037.A30936@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs This would help me. I have several RedHat 7.x systems running on XFS. They run great but now I see a potential problem with not being able to update. RedHat's 2.4.18-17.7 kernel does not show any dependency problems. Christoph Hellwig wrote: >On Tue, Oct 29, 2002 at 08:19:57AM +0100, Simon Matter wrote: > > >>I've installed the kernels mentioned above on several RH 7.2 servers. It >>has worked - like before - very well. The only problem I had was when >>upgrading my laptop. The PCMCIA stuff seems broken somehow and unloading >>kernel modules of PCMCIA devices just crashes the box. I'm sure the >>problem is that those new kernels were built on RedHat 8.0 which is >>quite different from 7.x. I then tried to rebuild from source RPM on >>RedHat 7.2. Building i386 and i586 packages went fine but i686 didn't. >>I'm happy anyway and thanks for the great product! >> >> > >The problem is that these kernel are built with gcc 3.2 - if you build the >pcmcia modules (or any other kernel module) with gcc 2.96 you'll get struct >mismatches. OTOH I'm not even sure whether there are external pcmcia >module on RH.. > >When I tried to build those kernel on my RH7.3 box I got internal compiler >error, but I have to admit I've not updated to the latest gcc eratta :) > >Maybe we should provide a gcc 2.96 built version for the RH7.x usesers, too.. > > > > -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Wed Oct 30 12:33:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 12:33:20 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UKX5uR028748 for ; Wed, 30 Oct 2002 12:33:06 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 3D35010951D for ; Wed, 30 Oct 2002 21:01:02 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E0E3C3.dip.t-dialin.net [217.224.227.195]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 61DC7109510 for ; Wed, 30 Oct 2002 21:01:01 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id 08FAFD15 for ; Wed, 30 Oct 2002 21:00:52 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 205D8A8 for ; Wed, 30 Oct 2002 21:00:51 +0100 (CET) Message-ID: <3DC03A72.9060800@koschikode.com> Date: Wed, 30 Oct 2002 21:00:50 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Joe St.Clair wrote: > I asked a couple of days ago about updating the kernel on a couple of > RedHat 7.x systems to 2.4.18-17.7. > This is the correct kernel version for the latest update on a RedHat 7.x > system. > > I have downloaded all of the command RPM's and the needed kernel RPM's. > When I test for dependencies it seems some other packages need to be > updated. Here is a list of what is needed. > > libc.so.6(GLIBC_2.3) > perl(strict) > LATEXFILE > /opt/cpg/bin/do-mgp > > It seems that the kernel on SGI's site have different dependencies that > the RedHat 2.4.18-17.7 one. Well, it depends. Unfortunately the new SGI RPMs are all build for RedHat 8.0! Seems that all users with RedHat 7.1 - 7.3 have to rebuild from the SRPMs :( Regards, Juri From owner-linux-xfs@oss.sgi.com Wed Oct 30 13:31:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 13:31:49 -0800 (PST) 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 g9ULVguR029724 for ; Wed, 30 Oct 2002 13:31:43 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA39143 for ; Wed, 30 Oct 2002 15:32:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA01863 for ; Wed, 30 Oct 2002 15:32:15 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9ULQcX24943; Wed, 30 Oct 2002 15:26:38 -0600 Message-Id: <200210302126.g9ULQcX24943@stout.americas.sgi.com> Date: Wed, 30 Oct 2002 15:26:38 -0600 Subject: TAKE - Remove remnants of readonly-mount handling X-archive-position: 1406 X-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 remnants of readonly-mount handling We were turning the VFS_RDONLY flag back on in xfs_qm_init_quotainos but that's no longer necessary, it's no longer turned off on ro mounts, except for recovery. Date: Wed Oct 30 13:31:49 PST 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:131553a linux/fs/xfs/xfs_qm.c - 1.91 From owner-linux-xfs@oss.sgi.com Wed Oct 30 13:35:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 13:35:04 -0800 (PST) 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 g9ULZ1uR030169 for ; Wed, 30 Oct 2002 13:35:01 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA63096 for ; Wed, 30 Oct 2002 15:35:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA34012 for ; Wed, 30 Oct 2002 15:35:35 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9ULTvG25036; Wed, 30 Oct 2002 15:29:57 -0600 Message-Id: <200210302129.g9ULTvG25036@stout.americas.sgi.com> Date: Wed, 30 Oct 2002 15:29:57 -0600 Subject: TAKE - Be more careful about quota state changes on ro-devices X-archive-position: 1407 X-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 Be more careful about quota state changes on ro-devices We can't allow quota state changes on a read-only device, this would kick of a failing transaction & shut down the fs. Previously the test was quota/no quota but we need to disallow any change wrt user and/or group quota state. Date: Wed Oct 30 13:35:08 PST 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:131554a linux/fs/xfs/xfs_mount.c - 1.309 From owner-linux-xfs@oss.sgi.com Wed Oct 30 14:00:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 14:00:07 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UM03uR000955 for ; Wed, 30 Oct 2002 14:00:03 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9UM0fA01047 for ; Wed, 30 Oct 2002 17:00:41 -0500 Message-ID: <3DC05699.8010206@ksimachine.com> Date: Wed, 30 Oct 2002 17:00:57 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs This would not be a big problem but I have never done this on a RedHat system. What I am looking for is some information on how to do this. Juri Haberland wrote: >Joe St.Clair wrote: > > >>I asked a couple of days ago about updating the kernel on a couple of >>RedHat 7.x systems to 2.4.18-17.7. >>This is the correct kernel version for the latest update on a RedHat 7.x >>system. >> >>I have downloaded all of the command RPM's and the needed kernel RPM's. >> When I test for dependencies it seems some other packages need to be >>updated. Here is a list of what is needed. >> >>libc.so.6(GLIBC_2.3) >>perl(strict) >>LATEXFILE >>/opt/cpg/bin/do-mgp >> >>It seems that the kernel on SGI's site have different dependencies that >>the RedHat 2.4.18-17.7 one. >> >> > >Well, it depends. Unfortunately the new SGI RPMs are all build for RedHat >8.0! Seems that all users with RedHat 7.1 - 7.3 have to rebuild from the >SRPMs :( > >Regards, >Juri > > > > -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Wed Oct 30 14:05:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 14:05:53 -0800 (PST) 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 g9UM5ouR001587 for ; Wed, 30 Oct 2002 14:05:51 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA70540; Wed, 30 Oct 2002 16:06:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA81116; Wed, 30 Oct 2002 16:06:23 -0600 (CST) Subject: Re: Question about kernel update From: Eric Sandeen To: ksimach@ksimachine.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DC05699.8010206@ksimachine.com> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 30 Oct 2002 16:00:45 -0600 Message-Id: <1036015245.18972.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1409 X-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 It's pretty straightforward, just get the kernel-foo.src.rpm, and then as root* do: rpmbuild --ba --target i686 kernel-foo.src.rpm and a few hours later, you should have shiny new RPMs in /usr/src/redhat/RPMS/i686 -Eric *you don't have to build RPMs as root but doing otherwise requires a longer explanation. :) On Wed, 2002-10-30 at 16:00, Joe St.Clair wrote: > This would not be a big problem but I have never done this on a RedHat > system. What I am looking for is some information on how to do this. > > Juri Haberland wrote: > >Well, it depends. Unfortunately the new SGI RPMs are all build for RedHat > >8.0! Seems that all users with RedHat 7.1 - 7.3 have to rebuild from the > >SRPMs :( -- 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 30 14:11:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 14:11:15 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UMBCuR002054 for ; Wed, 30 Oct 2002 14:11:13 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 7F06010951D for ; Wed, 30 Oct 2002 23:11:51 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E0E3C3.dip.t-dialin.net [217.224.227.195]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 3D27910951A for ; Wed, 30 Oct 2002 23:11:51 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id A4BDAD15 for ; Wed, 30 Oct 2002 23:11:47 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by warp9.sapienti-sat.org (Postfix) with ESMTP id F020A472 for ; Wed, 30 Oct 2002 23:11:44 +0100 (CET) Message-ID: <3DC05920.2010803@koschikode.com> Date: Wed, 30 Oct 2002 23:11:44 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Joe St.Clair wrote: > This would not be a big problem but I have never done this on a RedHat > system. What I am looking for is some information on how to do this. (there is an easier way, but I forgot) Just install the SRPMs and run 'rpm -bb /usr/src/redhat/SPECS/$sspecfile' where $specfile different from SRPM to SRPM. After the compilation you find the RPMs in /usr/src/redhat/RPMS/i386/. Regards, Juri > Juri Haberland wrote: > >>Joe St.Clair wrote: >> >>>I have downloaded all of the command RPM's and the needed kernel RPM's. >>> When I test for dependencies it seems some other packages need to be >>>updated. Here is a list of what is needed. >>> >>>libc.so.6(GLIBC_2.3) >>>perl(strict) >>>LATEXFILE >>>/opt/cpg/bin/do-mgp >>> >>>It seems that the kernel on SGI's site have different dependencies that >>>the RedHat 2.4.18-17.7 one. >> >>Well, it depends. Unfortunately the new SGI RPMs are all build for RedHat >>8.0! Seems that all users with RedHat 7.1 - 7.3 have to rebuild from the >>SRPMs :( From owner-linux-xfs@oss.sgi.com Wed Oct 30 14:15:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 14:15:42 -0800 (PST) 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 g9UMFduR002552 for ; Wed, 30 Oct 2002 14:15:40 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA36944; Wed, 30 Oct 2002 16:16:13 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA07563; Wed, 30 Oct 2002 16:16:12 -0600 (CST) Subject: Re: Question about kernel update From: Eric Sandeen To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com In-Reply-To: <1036015245.18972.23.camel@stout.americas.sgi.com> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 30 Oct 2002 16:10:34 -0600 Message-Id: <1036015835.20833.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1411 X-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 Whoops, that should probably be rpmbuild --rebuild --target i686 kernel-foo.src.rpm Or install it first, like Juri said. -Eric On Wed, 2002-10-30 at 16:00, Eric Sandeen wrote: > It's pretty straightforward, just get the kernel-foo.src.rpm, and then > as root* do: > > rpmbuild --ba --target i686 kernel-foo.src.rpm > -- 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 30 14:30:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 14:30:40 -0800 (PST) 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 g9UMUYuR003119 for ; Wed, 30 Oct 2002 14:30:35 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA11950 for ; Wed, 30 Oct 2002 16:31:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA13666 for ; Wed, 30 Oct 2002 16:31:07 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9UMPT228515; Wed, 30 Oct 2002 16:25:29 -0600 Message-Id: <200210302225.g9UMPT228515@stout.americas.sgi.com> Date: Wed, 30 Oct 2002 16:25:29 -0600 Subject: TAKE - Remove a couple other readonly device change remnants X-archive-position: 1412 X-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 were a couple other vestigial variables etc in the quota code, left over from the VFS_RDONLY toggling that was going on there. Remove a couple other readonly device change remnants Date: Wed Oct 30 14:30:14 PST 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:131565a linux/fs/xfs/xfs_qm.c - 1.92 From owner-linux-xfs@oss.sgi.com Wed Oct 30 15:06:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 15:06:20 -0800 (PST) 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 g9UN6DuR003832 for ; Wed, 30 Oct 2002 15:06:13 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA01461 for ; Wed, 30 Oct 2002 17:06:47 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA17955 for ; Wed, 30 Oct 2002 17:06:47 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9UN6mkq022211 for ; Wed, 30 Oct 2002 17:06:48 -0600 Subject: CVS tree now has complete history From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Oct 2002 17:06:47 -0600 Message-Id: <1036019208.19503.1618.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1413 X-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 The XFS trees on oss now has a complete set of files including all deleted files. Which means it is now possible to check out a tree from any point in time. i.e. cvs -q update -D2001/01/01 -d It is also possible to view revisions of files that have been moved. They will be in the Attic directory of the location they used to live in. -Russell Cattelan From owner-linux-xfs@oss.sgi.com Wed Oct 30 15:14:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 15:14:38 -0800 (PST) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UNEZuR004352 for ; Wed, 30 Oct 2002 15:14:35 -0800 Received: from splentec.com ([24.43.238.181]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021030231401.BKYG4551.fep02-mail.bloor.is.net.cable.rogers.com@splentec.com>; Wed, 30 Oct 2002 18:14:01 -0500 Message-ID: <3DC067F9.192BFE9C@splentec.com> Date: Wed, 30 Oct 2002 18:15:05 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.com> <20021030005632.A9930@infradead.org> <3DBF7E2F.57C503D@splentec.com> <20021030115210.A24361@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.43.238.181] using ID at Wed, 30 Oct 2002 18:14:01 -0500 X-archive-position: 1414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > > Why don't you comment on the other things I posted: > > (which I consider to be the real issues) > > - the pg locking clearly pulled in one place, > > - coalescing pagesync_t into pg with a single atomic var, > > - the if goto fiasco, > > - having extra code with one purpose: debugging, > > (not talking about BUG()) removed. > > - a centralized generic_make_request() calling scheme, > > rather than all over the place, > > - etc... > > This would make sense and help xfs improve, not nit-picking > > short conditionals. > > What about submitting one patch per change, with a usefull comment > instead of ranting? No, you are the one ranting. I did submit a patch. I did sumbit helpful to XFS improvement hints and suggestions. On whole I have had only 2 days of looking at the XFS code and thus I cannot be of any more help. I doubt I'll touch XFS code anymore, for reasons mentioned below. In fact all you do is wait for me to post something and then _you_ start ranting, offending, etc. Check the archives -- see for yourself. And why would I post a patch, after the attitude I've seen here? So that you can only attack it? Look, you get involved in arguing about short conditionals, which in a year or so everyone will be using... Look, all you do is preach kernel legalism here, rather than say what makes and what doesn't *make sense*, and this is what matters since this is how the kernel gets improved -- not by preaching legalism (like you do, getting cought up on setting bits), but by telling what *makes sense*. If everyone was like you -- the kernel would NOT have moved at all. Your behaviour here is NOT helpful to XFS improvement! As you can see none of your replies to me were of XFS improvement. It was only self-gratification, nit-picking and legalism, rather than, "yes that makes sense", and "no that doesn't make sense, but the same effect can be accomplished like so" -- you see, positiveness on the whole. How long have you waited to use the ``crack smoking'' phrase? You finally did. Bravo! I guess you want to find a mailing list, where you can reign free and attack ppl. Why don't you do this on linux-kernel? If you know so much about the XFS code and in general, why don't *you* post patches on the things you agree (agree?! -- yeah, right) are needed for XFS? You behaviour here is hardly professional and helpful to XFS. BUG 182 seems to be resolved. You've successfully managed to turn away another programmer from this list. The XFS team can thank you now. Good luck to the rest of you, -- Luben From owner-linux-xfs@oss.sgi.com Wed Oct 30 15:35:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 15:35:16 -0800 (PST) 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 g9UNZEuR005009 for ; Wed, 30 Oct 2002 15:35:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA18869; Wed, 30 Oct 2002 17:35:48 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA25320; Wed, 30 Oct 2002 17:35:48 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id g9UNZmkq022229; Wed, 30 Oct 2002 17:35:49 -0600 Subject: Re: [PATCH] page_buf stuff From: Russell Cattelan To: Luben Tuikov Cc: linux-xfs In-Reply-To: <3DC067F9.192BFE9C@splentec.com> References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.com> <20021030005632.A9930@infradead.org> <3DBF7E2F.57C503D@splentec.com> <20021030115210.A24361@infradead.org> <3DC067F9.192BFE9C@splentec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Oct 2002 17:35:48 -0600 Message-Id: <1036020949.19627.1655.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1415 X-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 Wed, 2002-10-30 at 17:15, Luben Tuikov wrote: [... rant deleted.. ] > You've successfully managed to turn away another programmer > from this list. The XFS team can thank you now. So if you has actually said something that would suggest you know how to program we might have actually considered you a programmer. :-) (clever syntax a programmer does not make) Ohh and for the record and to back up what Christoph said your interpretation of BH_Dirty is incorrect, his is. > > Good luck to the rest of you, > -- > Luben > From owner-linux-xfs@oss.sgi.com Wed Oct 30 15:53:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 15:53:03 -0800 (PST) Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UNr0uR006263 for ; Wed, 30 Oct 2002 15:53:01 -0800 Received: from splentec.com ([24.43.238.181]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021030235335.LYNQ4829.fep01-mail.bloor.is.net.cable.rogers.com@splentec.com>; Wed, 30 Oct 2002 18:53:35 -0500 Message-ID: <3DC070FE.CF63C2A4@splentec.com> Date: Wed, 30 Oct 2002 18:53:34 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs Subject: Re: [PATCH] page_buf stuff References: <3DBE3924.22B019A1@splentec.com> <1035899015.9794.13.camel@laptop.americas.sgi.com> <3DBF2B37.3440673D@splentec.com> <20021030005632.A9930@infradead.org> <3DBF7E2F.57C503D@splentec.com> <20021030115210.A24361@infradead.org> <3DC067F9.192BFE9C@splentec.com> <1036020949.19627.1655.camel@rose.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.43.238.181] using ID at Wed, 30 Oct 2002 18:53:34 -0500 X-archive-position: 1416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Russell Cattelan wrote: > > So if you has actually said something that would suggest you know how > to program we might have actually considered you a programmer. :-) > (clever syntax a programmer does not make) Yet another professional. Sorry, my drivers don't oops, and do make mount go in D state indefinitely. Take a look at pagebuf/*.c -- this can definitely be cleaned up. Don't you agree? (<-- careful what you answer here if your boss knows C) > Ohh and for the record and to back up what Christoph said your > interpretation of BH_Dirty is incorrect, his is. Really? But look: > > If the buffer should be written out, the dirty bit should be turned on. > > This makes sense anywhich way you look at it and think about it. > > This makes sense from 1. the code I've seen in the kernel (md) > > and from 2. logical point of view and from 3. my old OS course textbook > > (``the dinosaur book''). > It makes sense if you let the VM control the write out, but pagebuf > does the writeout explicit and the bit doesn't matter at all. So, he *does* say that it makes sense. Let's just do what makes sense -- that's all I'm saying. Take a look at the md code (mirroring, 2.4). Don't give me 2.5 as an example (which uses bios) -- it would be a red-herring. -- Luben From owner-linux-xfs@oss.sgi.com Wed Oct 30 17:58:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 17:58:55 -0800 (PST) Received: from athlon.random ([195.223.140.107]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V1wpuR009902 for ; Wed, 30 Oct 2002 17:58:52 -0800 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9V2xLDD004347; Thu, 31 Oct 2002 03:59:21 +0100 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9V1xEo1020252; Thu, 31 Oct 2002 02:59:14 +0100 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9V1xDc8020251; Thu, 31 Oct 2002 02:59:13 +0100 Date: Thu, 31 Oct 2002 02:59:13 +0100 From: Andrea Arcangeli To: Austin Gonyou Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Can anyone give me some diagnosis? Message-ID: <20021031015913.GI31040@dualathlon.random> References: <20021030184922.A2568@infradead.org> <1036003908.30032.10.camel@ubergeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1036003908.30032.10.camel@ubergeek> User-Agent: Mutt/1.3.27i X-GPG-Key: 1024D/68B9CB43 X-PGP-Key: 1024R/CB4660B9 X-archive-position: 1417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Wed, Oct 30, 2002 at 12:51:48PM -0600, Austin Gonyou wrote: > On Wed, 2002-10-30 at 12:49, Christoph Hellwig wrote: > [...] > > 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a > > resent > > XFS tree (like the ones in 2.4.20pre5aa and following). Also make sure > > you don't use a broken stack-eating storage driver like the qlogic ones. > > hrmm....that may be more difficult than it sounds...Is this error fatal? it's not fatal for sure, it's a warning, if you didn't notice anything wrong you can probably ignore it. > Is there something I can do to my 2.4.19-aa1, to just update the XFS > code, so our codebase for our kernels can just be versioned? I would > prefer to have our current 2.4.19 kernel, with updated xfs bits. > TIA. I will release a new -aa for 2.4.20-rc1 in a few days, you may want to try again with such new one. It has a recent xfs CVS code, thanks to Christoph for it. Andrea From owner-linux-xfs@oss.sgi.com Wed Oct 30 18:01:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 18:01:08 -0800 (PST) Received: from athlon.random ([195.223.140.107]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V214uR010312 for ; Wed, 30 Oct 2002 18:01:05 -0800 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g9V31ZDD004372; Thu, 31 Oct 2002 04:01:35 +0100 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g9V21So1020443; Thu, 31 Oct 2002 03:01:28 +0100 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g9V21STl020442; Thu, 31 Oct 2002 03:01:28 +0100 Date: Thu, 31 Oct 2002 03:01:28 +0100 From: Andrea Arcangeli To: Christoph Hellwig Cc: Austin Gonyou , linux-xfs@oss.sgi.com Subject: Re: Can anyone give me some diagnosis? Message-ID: <20021031020128.GJ31040@dualathlon.random> References: <20021030184922.A2568@infradead.org> <1036003908.30032.10.camel@ubergeek> <20021030185721.A2792@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021030185721.A2792@infradead.org> User-Agent: Mutt/1.3.27i X-GPG-Key: 1024D/68B9CB43 X-PGP-Key: 1024R/CB4660B9 X-archive-position: 1418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Wed, Oct 30, 2002 at 06:57:21PM +0000, Christoph Hellwig wrote: > On Wed, Oct 30, 2002 at 12:51:48PM -0600, Austin Gonyou wrote: > > On Wed, 2002-10-30 at 12:49, Christoph Hellwig wrote: > > [...] > > > 2.4.19-aa1 has XFS 1.1 that eats lots of stack. Please update to a > > > resent > > > XFS tree (like the ones in 2.4.20pre5aa and following). Also make sure > > > you don't use a broken stack-eating storage driver like the qlogic ones. > > > > hrmm....that may be more difficult than it sounds...Is this error fatal? > > Yes, stackoverflows can cause random memory corruption. we generate the warning when there's less than 1k available, 800 bytes of space are still a relevant amount (around a 10%) so it may not been fatal for him. Andrea From owner-linux-xfs@oss.sgi.com Wed Oct 30 19:12:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 19:12:44 -0800 (PST) Received: from smaux.kusm.kyoto-u.ac.jp (smaux.kusm.kyoto-u.ac.jp [130.54.53.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V3CfuR011876 for ; Wed, 30 Oct 2002 19:12:42 -0800 Received: (qmail 1508 invoked by alias); 31 Oct 2002 12:13:20 +0900 Received: (qmail 1497 invoked by uid 7794); 31 Oct 2002 12:13:20 +0900 Received: from matsuo@kusm.kyoto-u.ac.jp by smaux by uid 7791 with qmail-scanner-1.14 (sweep: 2.10/3.61. Clear:. Processed in 0.983064 secs); 31 Oct 2002 03:13:20 -0000 Received: from smaux.kusm.kyoto-u.ac.jp (HELO localhost) (172.23.1.12) by smaux.kusm.kyoto-u.ac.jp with SMTP; 31 Oct 2002 12:13:19 +0900 To: linux-xfs@oss.sgi.com Subject: mkfs.xfs destoroys sun disklabel X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-URL: http://www.kusm.kyoto-u.ac.jp/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> Date: Thu, 31 Oct 2002 12:13:18 +0900 From: Matsuo Hiroshi X-Dispatcher: imput version 980905(IM100) Lines: 49 X-archive-position: 1419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matsuo@kusm.kyoto-u.ac.jp Precedence: bulk X-list: linux-xfs Hi, I have linux-2.4.19 with xfs-1.2pre2 running on sparc (sun4m). I've found a problem about mkfx.xfs included in xfsprogs-2.3.5. If harddisk has only one partition, mkfx.xfs destoroy its disklabel. Hiroshi Matsuo ---------------------------------------------- # fdisk /dev/sdb Command (m for help): p Disk /dev/sdb (Sun disk label): 19 heads, 80 sectors, 2733 cylinders Units = cylinders of 1520 * 512 bytes Device Flag Start End Blocks Id System /dev/sdb1 0 2733 2077080 83 Linux native /dev/sdb3 0 2733 2077080 5 Whole disk Command (m for help): q # mkfs.xfs -f /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=8, agsize=64909 blks data = bsize=4096 blocks=519270, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # fdisk /dev/sdb Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new sun disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. . . . . . ---------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Oct 30 19:38:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 19:38:14 -0800 (PST) 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 g9V3c9uR012396 for ; Wed, 30 Oct 2002 19:38:09 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA04679; Wed, 30 Oct 2002 21:38:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA74990; Wed, 30 Oct 2002 21:38:44 -0600 (CST) Date: Wed, 30 Oct 2002 21:33:04 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Matsuo Hiroshi cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs destoroys sun disklabel In-Reply-To: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1420 X-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 - I don't know much about Sun disklabels - where do they live on the disk? mkfs.xfs does write to block 0 of the partition, so if something else is trying to live there... -Eric On Thu, 31 Oct 2002, Matsuo Hiroshi wrote: > Hi, > > I have linux-2.4.19 with xfs-1.2pre2 running on sparc (sun4m). > I've found a problem about mkfx.xfs included in xfsprogs-2.3.5. > > If harddisk has only one partition, mkfx.xfs destoroy its disklabel. > > > Hiroshi Matsuo > > ---------------------------------------------- > # fdisk /dev/sdb > > Command (m for help): p > > Disk /dev/sdb (Sun disk label): 19 heads, 80 sectors, 2733 cylinders > Units = cylinders of 1520 * 512 bytes > > Device Flag Start End Blocks Id System > /dev/sdb1 0 2733 2077080 83 Linux native > /dev/sdb3 0 2733 2077080 5 Whole disk > > Command (m for help): q > > # mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=8, agsize=64909 > blks > data = bsize=4096 blocks=519270, > imaxpct=25 > = sunit=0 swidth=0 blks, > unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200, version=1 > = sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > # fdisk /dev/sdb > Device contains neither a valid DOS partition table, nor Sun, SGI or > OSF disklabel > Building a new sun disklabel. Changes will remain in memory only, > until you decide to write them. After that, of course, the previous > content won't be recoverable. > . > . > . > . > . > > ---------------------------------------------- > > From owner-linux-xfs@oss.sgi.com Wed Oct 30 19:43:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 19:43:14 -0800 (PST) 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 g9V3hCuR012856 for ; Wed, 30 Oct 2002 19:43:12 -0800 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 TAA09794 for ; Wed, 30 Oct 2002 19:43:51 -0800 (PST) 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 OAA15410; Thu, 31 Oct 2002 14:42:32 +1100 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 g9V2fZu2001378; Thu, 31 Oct 2002 13:41:35 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g9V2fYeA001376; Thu, 31 Oct 2002 13:41:34 +1100 Date: Thu, 31 Oct 2002 13:41:34 +1100 From: Nathan Scott To: Matsuo Hiroshi Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs destoroys sun disklabel Message-ID: <20021031024134.GF641@frodo> References: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> User-Agent: Mutt/1.4i X-archive-position: 1421 X-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 Thu, Oct 31, 2002 at 12:13:18PM +0900, Matsuo Hiroshi wrote: > Hi, hi there. > I have linux-2.4.19 with xfs-1.2pre2 running on sparc (sun4m). > I've found a problem about mkfx.xfs included in xfsprogs-2.3.5. > > If harddisk has only one partition, mkfx.xfs destoroy its disklabel. > ... > # mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=8, agsize=64909 The -f option means "force" (as in "force" an overwrite, even if a filesystem/disk label signature was detected). I'd be interested to hear whether this correctly detects the Sun label without -f though (there's code in there to detect it, but I don't think I ever tested it on Sun labelled disks). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 30 21:01:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 21:01:41 -0800 (PST) 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 g9V51auR017870 for ; Wed, 30 Oct 2002 21:01:37 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA17143; Wed, 30 Oct 2002 23:02:11 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA73874; Wed, 30 Oct 2002 23:02:08 -0600 (CST) Date: Wed, 30 Oct 2002 22:56:27 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Luben Tuikov cc: Christoph Hellwig , Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff In-Reply-To: <3DBF7E2F.57C503D@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1422 X-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 Wed, 30 Oct 2002, Luben Tuikov wrote: > Christoph Hellwig wrote: > > > > On Tue, Oct 29, 2002 at 07:43:35PM -0500, Luben Tuikov wrote: > > > a ? a : b; <==> a ? : b; FWIW, it generates a warning on my compiler. I wanted to see if it generated any different assembly (I'm guessing it doesn't). > > > If the buffer should be written out, the dirty bit should be turned on. > > > This makes sense anywhich way you look at it and think about it. > > > This makes sense from 1. the code I've seen in the kernel (md) > > > and from 2. logical point of view and from 3. my old OS course textbook > > > (``the dinosaur book''). > > > > It makes sense if you let the VM control the write out, but pagebuf > > does the writeout explicit and the bit doesn't matter at all. > > So, you do admit that ``it makes sense ...'' -- so you agree with me. > (My god -- did you?! You'll now be ousted from linux-xfs!) That's not what he said. If you want the VM to write a buffer, you set it dirty. Then when it gets submitted, the dirty bit is cleared. As we do. > So, IOW, this would be *consistent* with the rest (VM, you mention). > So, let's be consistent. Let's turn on the dirty bit. This will be > consistent as if coming from the VM, you say... so the LL driver wouldn't > be playing guessing games where the thing came from... So let's just be > consistent. I'm curious as to why a lower-level driver would ever need to look at the state of the buffer. If the filesystem says "write this" shouldn't the lower level driver just do it, and not second-guess things? To me it makes sense that these flags should not affect lower level drivers. If you look at __block_write_full_page, brw_kiovec, journal_commit_transaction, submit_bh_for_writepage, and others, the kernel paradigm is to -clear- the dirty bit and -set- uptodate before the buffer is submitted to lower levels. I guess this is because those lower levels are expected to do their job, i.e. write the thing to disk, so it will no longer be dirty, and will now be uptodate. > > Look at fs/buffer.c - usually we set it before submitting and clear > > it if the I/O failed. And yes, this is confusing when you look > > at it. > > Why are you repeating what I'm saying? You alrealy admit that > it is confusing so what is the value and purpose of your post here? > > Why not just admit that this is the reversed logic, and have the > io completion callback worry about the Uptodate bit. > Logically Uptodate is false, before the buffer has been written out > to the media (for WRITE operations). And I try to only do things > which *make sense*. You also need to do things that are consistent with what everyone working on the kernel will expect. If you feel that it is important to set Uptodate only after you know that the buffer has been written, then you need to take that crusade to LKML in general, I think. > > Drivers should never ever look at BH_Dirty. > > (Can you guarantee that no such (stacking) drivers exist?) Can you show me one that does? :) And is it generally considered correct? > I see md does it, implicitly by turning it on -- I guess it's > just being consistent. I don't know enough about md to comment on why they do it this way. > Why don't you comment on the other things I posted: > (which I consider to be the real issues) > - the pg locking clearly pulled in one place, > - coalescing pagesync_t into pg with a single atomic var, > - the if goto fiasco, Hardly a fiasco, more of a coding style, perhaps it could be cleaned up, if you have a patch that makes the code clearer, submit it. > - having extra code with one purpose: debugging, > (not talking about BUG()) removed. What code is this? There is plenty of debug-specific code in xfs, if some of it is compiled for non-debug kernels, please point this out. Debugging code is there for a reason, though. > - a centralized generic_make_request() calling scheme, > rather than all over the place, > - etc... You'll find that we don't have much time to respond to "would be nice" types of patches. As you've probably seen on the list, when someone submits a patch that clearly fixes a bug, and can demonstrate that it is correct, it gets accepted and applied. Your "Page buf stuff" patch seems to do 4 things: 1) re-write a conditional 2) invert buffer head flag settings (discussed above) 3) make a new loop just for submitting the buffer heads, and 4) run tq_disk 1 and 3 seem to be no-ops, 2 seems to be incorrect (although I understand that you disagree), and it's not clear why 4 is there, Steve feels that it will adversely affect performance. If you can show otherwise, please do. -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 30 21:07:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 21:07:32 -0800 (PST) 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 g9V57UuR018368 for ; Wed, 30 Oct 2002 21:07:30 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id DB4641EEE09; Wed, 30 Oct 2002 21:08:10 -0800 (PST) Date: Wed, 30 Oct 2002 21:08:10 -0800 From: Chris Wedgwood To: Matsuo Hiroshi Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs destoroys sun disklabel Message-ID: <20021031050810.GA18317@tapu.f00f.org> References: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031121318C.matsuo@kusm.kyoto-u.ac.jp> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1423 X-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 31, 2002 at 12:13:18PM +0900, Matsuo Hiroshi wrote: > # mkfs.xfs -f /dev/sdb1 -f -> force if it hurts, then don't do that --cw From owner-linux-xfs@oss.sgi.com Wed Oct 30 21:19:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 21:19:55 -0800 (PST) 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 g9V5JruR018880 for ; Wed, 30 Oct 2002 21:19:53 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA68780; Wed, 30 Oct 2002 23:20:28 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id XAA95014; Wed, 30 Oct 2002 23:20:28 -0600 (CST) Date: Wed, 30 Oct 2002 23:14:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Nathan Scott cc: Matsuo Hiroshi , Subject: Re: mkfs.xfs destoroys sun disklabel In-Reply-To: <20021031024134.GF641@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1424 X-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, 31 Oct 2002, Nathan Scott wrote: > The -f option means "force" (as in "force" an overwrite, even if > a filesystem/disk label signature was detected). > > I'd be interested to hear whether this correctly detects the Sun > label without -f though (there's code in there to detect it, but > I don't think I ever tested it on Sun labelled disks). It does work... I sacrificed a disk to find out. :) [root@lite root]# mkfs.xfs /dev/sda1 mkfs.xfs: /dev/sda1 appears to contain a partition table (Sun). mkfs.xfs: Use the -f option to force overwrite. The fdisk man page also warns about this: Do not start a partition that actually uses its first sector (like a swap partition) at cylinder 0, since that will destroy the disklabel. Maybe we should ask the fdisk maintainer to add xfs to that warning. :) -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 30 22:31:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Oct 2002 22:31:08 -0800 (PST) Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V6V1uR022372 for ; Wed, 30 Oct 2002 22:31:02 -0800 Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g9V6Utf31149; Thu, 31 Oct 2002 01:30:55 -0500 Message-ID: <3DC0CE1F.2DF2F060@splentec.com> Date: Thu, 31 Oct 2002 01:30:55 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Christoph Hellwig , Stephen Lord , linux-xfs Subject: Re: [PATCH] page_buf stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luben@splentec.com Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: > > I'm curious as to why a lower-level driver would ever need to look at the > state of the buffer. If the filesystem says "write this" shouldn't > the lower level driver just do it, and not second-guess things? To > me it makes sense that these flags should not affect lower level drivers. > > If you look at __block_write_full_page, brw_kiovec, journal_commit_transaction, > submit_bh_for_writepage, and others, the kernel paradigm is to > -clear- the dirty bit and -set- uptodate before the buffer is submitted > to lower levels. I guess this is because those lower levels are expected > to do their job, i.e. write the thing to disk, so it will no longer be dirty, > and will now be uptodate. I had been looking at md. Uptodate is off and dirty is on in the md code. This behaviour also seems to make logical sense to me -- i.e. taking a pessimistic view. > You also need to do things that are consistent with what everyone working > on the kernel will expect. If you feel that it is important to set Uptodate > only after you know that the buffer has been written, then you need to take > that crusade to LKML in general, I think. Thanks for the mocking, but no, I don't have any particular feeling regarding this, other than what I've mentioned makes sense to me (logically), AND have seen it in the md code. E.g. raid1.c, line 674-5 does: mbh->b_state = (1< Can you show me one that does? :) And is it generally considered correct? No, but I don't want to take my chances, as I said. ``Generally considered correct''? -- I cannot speak for other ppl. I saw it in md, and logically made sense to me (things I've read, seen, etc), that's all. > Hardly a fiasco, more of a coding style, perhaps it could be cleaned > up, if you have a patch that makes the code clearer, submit it. Idealistically speaking, (I'm one such), it does make a difference for such small, insignificant patches to go in, so that after 10-20 of them, the code may be cleaner and have better design. OTOH, I got involved with XFS just to submit and track bug 182, since we've been getting it for many months, but before I had other things to do (priorites). Then I got free and I was asked to take a look at this and spent less than 2 days total looking at the thing. With such little time on xfs, I'll never submit a serious patch. And as you can see, the original post had one sentence in it: ``Maybe like this?'' -- it was never a serious patch, I never intended it to be. > > - having extra code with one purpose: debugging, > > (not talking about BUG()) removed. > > What code is this? There is plenty of debug-specific code in xfs, if > some of it is compiled for non-debug kernels, please point this out. > Debugging code is there for a reason, though. Ok, I understand. My mistake. My (idealistic) position is that kernel debuggers are not very helpful and if code needs code to debug it, then the whole thing needs rewriting. > > - a centralized generic_make_request() calling scheme, > > rather than all over the place, > > - etc... > > You'll find that we don't have much time to respond to "would be nice" > types of patches. As you've probably seen on the list, when someone > submits a patch that clearly fixes a bug, and can demonstrate that it is > correct, it gets accepted and applied. This wasn't one of those ``would be nice'', it was more of a ``maybe better and cleaner approach''. But, I don't care anymore. XFS now works with lvm and md underneath it -- that's all that matters now. Who cares what the code actually looks like? > Your "Page buf stuff" patch seems to do 4 things: > > 1) re-write a conditional > 2) invert buffer head flag settings (discussed above) > 3) make a new loop just for submitting the buffer heads, and > 4) run tq_disk > > 1 and 3 seem to be no-ops, Sure. If you look, you'll see that the original posting had ``maybe like this?'' sentence at the begining (the only one). OTOH, moving generic_make_request() out and a few more of those ``no-ops'' as you call them, will start to make for a cleaner and more manageable code. Didn't I get a reply, something of the sort: ``so many eyes have looked at this code ....''? -- My point exactly. Think only that, BEFORE the patch from Asano, that same 3) would have looked like a no-ops to you, but that's all that was needed to get rid of bug 182. In fact, 3) or the patch from Asano. > 2 seems to be incorrect (although I understand that you disagree), No, I don't care. Has nothing to do with agreeing. > and it's not clear why 4 is there, Steve feels that it > will adversely affect performance. If you can show otherwise, please do. The whole point was to have run_task_queue(&tq_disk) pulled out in _one_ place, nicely and cleanly. Does XFS now work with LVM and md? -- Yes. So, now I'll go back to the other things I need and have to do. Good luck to all of you, -- Luben From owner-linux-xfs@oss.sgi.com Thu Oct 31 00:22:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 00:22:41 -0800 (PST) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V8MbuR026558 for ; Thu, 31 Oct 2002 00:22:38 -0800 Received: by sundancer.oche.de (Postfix, from userid 10) id 6697955FF1; Thu, 31 Oct 2002 09:23:11 +0100 (CET) Received: (from martin@localhost) by foehn.quickstep.oche.de (8.9.3/8.6.12) id JAA06568; Thu, 31 Oct 2002 09:00:10 +0100 (CET) Date: Thu, 31 Oct 2002 09:00:10 +0100 (CET) Message-Id: <200210310800.JAA06568@foehn.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs destoroys sun disklabel In-Reply-To: Organization: home User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.8 (sun4m)) X-archive-position: 1426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs > I have linux-2.4.19 with xfs-1.2pre2 running on sparc (sun4m). > I've found a problem about mkfx.xfs included in xfsprogs-2.3.5. > If harddisk has only one partition, mkfx.xfs destoroy its disklabel. The Sun disklabel lives within the first 64 kByte (as I remember from memory) of the disk. Sun UFS excludes this area from being used in purpose not to destroy the label. If you are placing anything else on the disk that is not aware of the necessity of this workaround, then you should avoid including the first cylinder ("0") into the slice (I had similar experience on Solaris with placing a Sybase device into the first slice), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Oct 31 02:13:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 02:13:41 -0800 (PST) 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 g9VADbuR031762 for ; Thu, 31 Oct 2002 02:13:38 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 0C0E7AC51; Thu, 31 Oct 2002 11:08:31 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 9E82A190D2; Thu, 31 Oct 2002 11:08:29 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 80ED530881D; Thu, 31 Oct 2002 11:14:16 +0100 (CET) Message-ID: <3DC10278.7E2BCA9A@ch.sauter-bc.com> Date: Thu, 31 Oct 2002 11:14:16 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Christoph Hellwig Cc: Eric Sandeen , ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: patch howto??? References: <3DBDAC4A.40001@ksimachine.com> <1035841498.8560.17.camel@stout.americas.sgi.com> <20021028220654.B31860@infradead.org> <3DBE369D.DEAA0608@ch.sauter-bc.com> <20021030164037.A30936@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1427 X-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 Christoph Hellwig schrieb: > > On Tue, Oct 29, 2002 at 08:19:57AM +0100, Simon Matter wrote: > > I've installed the kernels mentioned above on several RH 7.2 servers. It > > has worked - like before - very well. The only problem I had was when > > upgrading my laptop. The PCMCIA stuff seems broken somehow and unloading > > kernel modules of PCMCIA devices just crashes the box. I'm sure the > > problem is that those new kernels were built on RedHat 8.0 which is > > quite different from 7.x. I then tried to rebuild from source RPM on > > RedHat 7.2. Building i386 and i586 packages went fine but i686 didn't. > > I'm happy anyway and thanks for the great product! > > The problem is that these kernel are built with gcc 3.2 - if you build the > pcmcia modules (or any other kernel module) with gcc 2.96 you'll get struct > mismatches. OTOH I'm not even sure whether there are external pcmcia > module on RH.. > > When I tried to build those kernel on my RH7.3 box I got internal compiler > error, but I have to admit I've not updated to the latest gcc eratta :) > > Maybe we should provide a gcc 2.96 built version for the RH7.x usesers, too.. Would be very nice. I tried on RH 7.2 with all errata updates but the i686 kernel didn't compile too. BTW, errata packages are almost always the same for 7.2 and 7.3. From owner-linux-xfs@oss.sgi.com Thu Oct 31 02:32:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 02:32:53 -0800 (PST) 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 g9VAWouR032324 for ; Thu, 31 Oct 2002 02:32:50 -0800 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 CAA08465 for ; Thu, 31 Oct 2002 02:33:30 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA57482 for linux-xfs@oss.sgi.com; Thu, 31 Oct 2002 21:32:14 +1100 (EST) Date: Thu, 31 Oct 2002 21:32:14 +1100 (EST) From: Nathan Scott Message-Id: <200210311032.VAA57482@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix lurking compile error X-archive-position: 1428 X-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 compile error with XFS_BIG_FILESYSTEMS set - too many braces. Date: Thu Oct 31 02:31:13 PST 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:131618a linux/fs/xfs/xfs_bmap_btree.c - 1.132 - Fix compile error with XFS_BIG_FILESYSTEMS set. From owner-linux-xfs@oss.sgi.com Thu Oct 31 03:36:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 03:36:13 -0800 (PST) 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 g9VBaBuR002836 for ; Thu, 31 Oct 2002 03:36:11 -0800 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 DAA06696 for ; Thu, 31 Oct 2002 03:36:52 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id WAA61422 for linux-xfs@oss.sgi.com; Thu, 31 Oct 2002 22:35:35 +1100 (EST) Date: Thu, 31 Oct 2002 22:35:35 +1100 (EST) From: Nathan Scott Message-Id: <200210311135.WAA61422@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - userspace updates X-archive-position: 1429 X-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 attr/acl updates - Debian packaging, closing some Debian-specific bugs. xfsprogs updates - initial sync up with recent kernel changes (not quite complete yet); bump version; move some common headers to a common place; fix several compiler warnings with recent gcc versions (3.2+). Changes to configure-generated files, so a "make distclean" is needed here. cheers. Date: Thu Oct 31 02:54:49 PST 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:131619a cmd/acl/VERSION - 1.38 cmd/acl/doc/CHANGES - 1.45 cmd/acl/debian/control - 1.9 cmd/acl/debian/changelog - 1.32 cmd/attr/VERSION - 1.25 cmd/attr/doc/CHANGES - 1.32 cmd/attr/debian/control - 1.8 cmd/attr/debian/changelog - 1.26 - Updates to Debian packaging, closing out some Debian-specific bugs. Date: Thu Oct 31 02:56:16 PST 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:131620a cmd/xfsdump/VERSION - 1.42 cmd/xfsdump/doc/CHANGES - 1.50 cmd/xfsdump/debian/control - 1.12 cmd/xfsdump/debian/changelog - 1.33 - Bump version for recent bugfix and several Debian packaging related mods. Date: Thu Oct 31 03:24:20 PST 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:131621a cmd/xfsprogs/VERSION - 1.61 cmd/xfsprogs/doc/CHANGES - 1.86 cmd/xfsprogs/debian/changelog - 1.54 - bump version, document changes. cmd/xfsprogs/db/mount.c - 1.5 - Fix mount path to make better use of libxfs routines instead of using local copies. Needed for merge of fix for dir/ea block split change. cmd/xfsprogs/db/convert.c - 1.5 cmd/xfsprogs/db/check.c - 1.9 cmd/xfsprogs/bmap/xfs_bmap.c - 1.11 cmd/xfsprogs/imap/xfs_imap.c - 1.6 cmd/xfsprogs/rtcp/xfs_rtcp.c - 1.9 cmd/xfsprogs/freeze/xfs_freeze.c - 1.6 cmd/xfsprogs/mkfile/xfs_mkfile.c - 1.11 cmd/xfsprogs/libxfs/rdwr.c - 1.13 cmd/xfsprogs/libxfs/xfs.h - 1.25 cmd/xfsprogs/include/platform_defs.h.in - 1.12 - Keep commonly repeated headers along with all the other common headers. Fix minor warnings with more recent versions of gcc. cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.17 cmd/xfsprogs/include/xfs_da_btree.h - 1.13 cmd/xfsprogs/include/libxfs.h - 1.19 cmd/xfsprogs/include/xfs_mount.h - 1.30 cmd/xfsprogs/repair/dir2.c - 1.11 cmd/xfsprogs/repair/dir.c - 1.10 cmd/xfsprogs/repair/sb.c - 1.8 cmd/xfsprogs/repair/phase1.c - 1.5 cmd/xfsprogs/repair/incore.c - 1.6 cmd/xfsprogs/repair/incore_ino.c - 1.7 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.19 cmd/xfsprogs/libxfs/xfs_dir.c - 1.11 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.11 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.12 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.11 - Sync up with recent kernel source changes (esp. dir/ea block split change). From owner-linux-xfs@oss.sgi.com Thu Oct 31 03:38:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 03:38:36 -0800 (PST) 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 g9VBcXuR003281 for ; Thu, 31 Oct 2002 03:38:34 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 92B54AC40; Thu, 31 Oct 2002 12:33:27 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 5DBA5190DD; Thu, 31 Oct 2002 12:33:26 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 4935A30881D; Thu, 31 Oct 2002 12:39:13 +0100 (CET) Message-ID: <3DC11661.195592BC@ch.sauter-bc.com> Date: Thu, 31 Oct 2002 12:39:13 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1430 X-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 Eric Sandeen schrieb: > > It's pretty straightforward, just get the kernel-foo.src.rpm, and then > as root* do: > > rpmbuild --ba --target i686 kernel-foo.src.rpm > > and a few hours later, you should have shiny new RPMs in > /usr/src/redhat/RPMS/i686 I whish it was like that :) Unfortunately the i386 and i586 kernel build fine but the i686 one doesn't build. Does one of the gurus know the fix? Simon > > -Eric > > *you don't have to build RPMs as root but doing otherwise requires a > longer explanation. :) > > On Wed, 2002-10-30 at 16:00, Joe St.Clair wrote: > > This would not be a big problem but I have never done this on a RedHat > > system. What I am looking for is some information on how to do this. > > > > Juri Haberland wrote: > > > >Well, it depends. Unfortunately the new SGI RPMs are all build for RedHat > > >8.0! Seems that all users with RedHat 7.1 - 7.3 have to rebuild from the > > >SRPMs :( > > -- > 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 Thu Oct 31 05:30:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 05:30:52 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VDUjuR007745 for ; Thu, 31 Oct 2002 05:30:46 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 187FOi-0003YN-00 for ; Thu, 31 Oct 2002 14:30:08 +0100 To: linux-xfs@oss.sgi.com X-Injected-Via-Gmane: http://gmane.org/ Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 186zcg-0002KS-00 for ; Wed, 30 Oct 2002 21:39:30 +0100 Path: not-for-mail From: Nicholas Wourms Subject: linux-2.5 tree changes? Date: Wed, 30 Oct 2002 15:41:45 -0500 Lines: 9 Message-ID: Reply-To: nwourms@netscape.net NNTP-Posting-Host: 130-127-121-177.generic.clemson.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: main.gmane.org 1036010370 8954 130.127.121.177 (30 Oct 2002 20:39:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 30 Oct 2002 20:39:30 +0000 (UTC) User-Agent: KNode/0.7.2 X-archive-position: 1431 X-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 just went to sync my linux-2.5-xfs cvs tree with HEAD, and it deleted most of the kernel plus kdb. Is there something going on? Is KDB being dropped? I have no idea when this was done, since you have no Attic/, so sorry if this message was sent too soon... Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Thu Oct 31 05:52:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 05:52:49 -0800 (PST) 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 g9VDqluR008448 for ; Thu, 31 Oct 2002 05:52:47 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA07387; Thu, 31 Oct 2002 07:53:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA07613; Thu, 31 Oct 2002 07:53:23 -0600 (CST) Date: Thu, 31 Oct 2002 07:47:39 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Nicholas Wourms cc: linux-xfs@oss.sgi.com Subject: Re: linux-2.5 tree changes? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1432 X-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 Nicholas - I know Russell just changed the way CVS is exported, perhaps there is a problem. We'll look into it today. -Eric On Wed, 30 Oct 2002, Nicholas Wourms wrote: > Hi, > > I just went to sync my linux-2.5-xfs cvs tree with HEAD, and it deleted most > of the kernel plus kdb. Is there something going on? Is KDB being > dropped? I have no idea when this was done, since you have no Attic/, so > sorry if this message was sent too soon... > > Cheers, > Nicholas > > > From owner-linux-xfs@oss.sgi.com Thu Oct 31 07:04:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 07:04:25 -0800 (PST) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VF4IuR013538 for ; Thu, 31 Oct 2002 07:04:19 -0800 Received: from nwourms@netscape.net by imo-d07.mx.aol.com (mail_out_v34.13.) id 5.56.535052f (16226); Thu, 31 Oct 2002 10:04:09 -0500 (EST) Received: from netscape.net ([130.127.122.186]) by air-in02.mx.aol.com (v89.12) with ESMTP id MAILININ22-1031100409; Thu, 31 Oct 2002 10:04:09 -0400 Message-ID: <3DC1465F.2090502@netscape.net> Date: Thu, 31 Oct 2002 10:03:59 -0500 From: Nicholas Wourms User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: linux-2.5 tree changes? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) X-archive-position: 1433 X-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 Eric Sandeen wrote: > Hi Nicholas - > > I know Russell just changed the way CVS is exported, perhaps there is a problem. > We'll look into it today. > Eric, That message was supposed to be sent last night, but due to problems with Netscape's SMTP server, it apparently was delayed. Anyhow, I noticed, earlier this morning, that the missing directories and files were restored. Sorry for the false alarm. Cheers, Nicholas From owner-linux-xfs@oss.sgi.com Thu Oct 31 08:05:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 08:05:26 -0800 (PST) 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 g9VG5IuR018945 for ; Thu, 31 Oct 2002 08:05:18 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA98058 for ; Thu, 31 Oct 2002 10:05:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA15423 for ; Thu, 31 Oct 2002 10:05:55 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g9VG5aV21212; Thu, 31 Oct 2002 10:05:36 -0600 Message-Id: <200210311605.g9VG5aV21212@jen.americas.sgi.com> Date: Thu, 31 Oct 2002 10:05:36 -0600 Subject: TAKE - remove VPURGE To: linux-xfs@oss.sgi.com X-archive-position: 1434 X-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 was a relic of some old linux specific code. Thanks to Eric for noticing it. Date: Thu Oct 31 07:59:08 PST 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:131630a linux/fs/xfs/xfs_vfsops.c - 1.397 linux/fs/xfs/xfs_mount.c - 1.310 linux/fs/xfs/xfs_inode.c - 1.359 linux/fs/xfs/linux/xfs_vnode.c - 1.103 linux/fs/xfs/linux/xfs_super.c - 1.226 linux/fs/xfs/linux/xfs_vnode.h - 1.68 From owner-linux-xfs@oss.sgi.com Thu Oct 31 08:38:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 08:38:17 -0800 (PST) Received: from imf06bis.bellsouth.net (mail106.mail.bellsouth.net [205.152.58.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VGc4uR019949 for ; Thu, 31 Oct 2002 08:38:04 -0800 Received: from TAZ2 ([66.156.1.8]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021031164025.OSYR20501.imf06bis.bellsouth.net@TAZ2> for ; Thu, 31 Oct 2002 11:40:25 -0500 Date: Thu, 31 Oct 2002 11:38:35 -0500 From: Greg Freemyer Subject: Lockup with LVM snapshot To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021031164025.OSYR20501.imf06bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VGc6uR019955 X-archive-position: 1435 X-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 I have a test machine which has started locking up when I run my backup script. The script creates a LVM snapshot for each of 3 LVs in turn and then uses xfsdump to back them up. After the lockup, nothing seems to work, but the keyboard lights are flashing. I'm running a pure CVS kernel from Sept. 6. My warn.log file has: Oct 20 01:15:22 TruStore1000 kernel: XFS mounting filesystem lvm(58,4) Oct 20 01:15:28 TruStore1000 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/TruStore-Data/config_snap Oct 20 01:15:28 TruStore1000 kernel: I/O error in filesystem ("lvm(58,4)") meta-data dev 0x3a04 block 0x1a5c8 Oct 20 01:15:28 TruStore1000 kernel: ("xlog_iodone") error 5 buf count 2560 Oct 20 01:15:28 TruStore1000 kernel: xfs_force_shutdown(lvm(58,4),0x2) called from line 949 of file xfs_log.c. Return address = 0xc022b827 Oct 20 01:15:28 TruStore1000 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,4) Oct 20 01:15:28 TruStore1000 kernel: Please umount the filesystem, and rectify the problem(s) Oct 20 01:15:29 TruStore1000 kernel: XFS mounting filesystem lvm(58,3) The filesystem config_snap has already been deleted. I have not tried to reproduce this, but I suspect I can. It has happened twice so far. Is it likely a updated CVS kernel would fix this? Is there more data I can provide? Thanks, Greg ============= Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Oct 31 08:57:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 08:57:32 -0800 (PST) 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 g9VGvTuR021210 for ; Thu, 31 Oct 2002 08:57:30 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA89960; Thu, 31 Oct 2002 10:58:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA47835; Thu, 31 Oct 2002 10:58:06 -0600 (CST) Subject: Re: Lockup with LVM snapshot From: Eric Sandeen To: Greg Freemyer Cc: xfs mailing list In-Reply-To: <20021031164025.OSYR20501.imf06bis.bellsouth.net@TAZ2> References: <20021031164025.OSYR20501.imf06bis.bellsouth.net@TAZ2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Oct 2002 10:52:21 -0600 Message-Id: <1036083141.921.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1436 X-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 Greg - Flashing lights means you're in kdb... but if you're in X, you're stuck there. Blindly typing "go" may get you going again. I put a fix in recently that prevents XFS from generating a transaction on a read-only snapshot, I'm guessing this is the same thing you're hitting. (if, for some reason (post-crash?) there are files with blocks past eof, xfs would try to clean those up, even if the underlying device is read-only, which will fail). You might try the very latest CVS code, or grab the next 1.2 prerelease that's available. Alternatively, if you tar up the "live" filesystem once, it will probably fix up the state of any files that may be causing this problem. -Eric On Thu, 2002-10-31 at 10:38, Greg Freemyer wrote: > I have a test machine which has started locking up when I run my backup script. > > The script creates a LVM snapshot for each of 3 LVs in turn and then uses xfsdump to back them up. > > After the lockup, nothing seems to work, but the keyboard lights are flashing. > > I'm running a pure CVS kernel from Sept. 6. > > My warn.log file has: > > Oct 20 01:15:22 TruStore1000 kernel: XFS mounting filesystem lvm(58,4) > Oct 20 01:15:28 TruStore1000 kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/TruStore-Data/config_snap > Oct 20 01:15:28 TruStore1000 kernel: I/O error in filesystem ("lvm(58,4)") meta-data dev 0x3a04 block 0x1a5c8 > Oct 20 01:15:28 TruStore1000 kernel: ("xlog_iodone") error 5 buf count 2560 > Oct 20 01:15:28 TruStore1000 kernel: xfs_force_shutdown(lvm(58,4),0x2) called from line 949 of file xfs_log.c. Return address = 0xc022b827 > Oct 20 01:15:28 TruStore1000 kernel: Log I/O Error Detected. Shutting down filesystem: lvm(58,4) > Oct 20 01:15:28 TruStore1000 kernel: Please umount the filesystem, and rectify the problem(s) > Oct 20 01:15:29 TruStore1000 kernel: XFS mounting filesystem lvm(58,3) > > The filesystem config_snap has already been deleted. > > I have not tried to reproduce this, but I suspect I can. It has happened twice so far. > > Is it likely a updated CVS kernel would fix this? > > Is there more data I can provide? > > Thanks, > Greg > ============= > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 v4, v5 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com > -- 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 Thu Oct 31 09:02:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 09:02:59 -0800 (PST) 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 g9VH2ruR021715 for ; Thu, 31 Oct 2002 09:02:53 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA43621 for ; Thu, 31 Oct 2002 11:03:25 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA73048 for ; Thu, 31 Oct 2002 11:03:25 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g9VGveH06740; Thu, 31 Oct 2002 10:57:40 -0600 Message-Id: <200210311657.g9VGveH06740@stout.americas.sgi.com> Date: Thu, 31 Oct 2002 10:57:40 -0600 Subject: TAKE - Fix up spec files in userspace cmds X-archive-position: 1437 X-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 Fix up spec files: Make packager, vendor consistent, as Silicon Graphics, Inc. Remove Copyright: tag, as this seems to actually be an alias for License, and add a License: GPL tag. (Otherwise querying the package whould show "License: Copyright Silicon Graphics..." which really doesn't make sense) Date: Thu Oct 31 09:02:59 PST 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:131639a cmd/acl/build/rpm/acl.spec.in - 1.9 cmd/attr/build/rpm/attr.spec.in - 1.11 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.13 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.11 cmd/dmapi/build/rpm/dmapi.spec.in - 1.13 From owner-linux-xfs@oss.sgi.com Thu Oct 31 09:47:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 09:47:18 -0800 (PST) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VHlBuR022532 for ; Thu, 31 Oct 2002 09:47:12 -0800 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id g9VHnl5f021938 for ; Thu, 31 Oct 2002 10:49:47 -0700 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id g9VHnlGY021935 for ; Thu, 31 Oct 2002 10:49:47 -0700 Date: Thu, 31 Oct 2002 10:49:47 -0700 (MST) From: James Rich To: XFS mailing list Subject: performance over multiple disks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs On another mailing list a debate arose about performance over a single disk vs. multiple disks. It goes something like this: Suppose you have a 6 megabyte file stored on disk. Would it be read faster if it were stored contiguously on a single disk or spread over multiple (say 4) disks? It seems to me that as you get smaller it is faster for the single disk case (remember that we are assuming the file is stored contiguously - not spread all over the disk). At some size it seems natural that it would be faster if the file were spread over multiple disks. Can anyone comment on how XFS would perform? I don't have the equipment available to test this, but I'm not too concerned with actual benchmark numbers. Mostly I'm just wondering if I understand the filesystem correctly. James Rich From owner-linux-xfs@oss.sgi.com Thu Oct 31 10:16:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 10:16:05 -0800 (PST) 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 g9VIFxuR023214 for ; Thu, 31 Oct 2002 10:16:01 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 8613F1EEFE9; Thu, 31 Oct 2002 10:16:42 -0800 (PST) Date: Thu, 31 Oct 2002 10:16:42 -0800 From: Chris Wedgwood To: James Rich Cc: XFS mailing list Subject: Re: performance over multiple disks Message-ID: <20021031181642.GA24092@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: 1439 X-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 31, 2002 at 10:49:47AM -0700, James Rich wrote: > Suppose you have a 6 megabyte file stored on disk. Would it be read > faster if it were stored contiguously on a single disk or spread > over multiple (say 4) disks? It depends.... but usually data over multiple disks reads faster, sometimes n-times the speed of a single disk (but not always). --cw From owner-linux-xfs@oss.sgi.com Thu Oct 31 10:33:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 10:34:02 -0800 (PST) Received: from imf25bis.bellsouth.net (mail229.mail.bellsouth.net [205.152.58.199]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VIXvuR023791 for ; Thu, 31 Oct 2002 10:33:58 -0800 Received: from TAZ2 ([66.156.1.8]) by imf25bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021031183620.NQJW3311.imf25bis.bellsouth.net@TAZ2>; Thu, 31 Oct 2002 13:36:20 -0500 Date: Thu, 31 Oct 2002 13:34:29 -0500 From: Greg Freemyer Subject: re[2]: Lockup with LVM snapshot To: Eric Sandeen cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021031183620.NQJW3311.imf25bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VIXwuR023794 X-archive-position: 1440 X-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 Thanks Eric, Current CVS kernel does indeed allow my backup to run. It is obvious that you guys have made a number of improvements in XFS/LVS integration in the last several months. I'm looking forward to the real 1.2 release. One question: do I still have an unusual data/meta-data problem on my LV that this kernel handles better Or did this kernel fix the on disk data itself and now I could go back to the old kernel? Greg >> Greg - >> Flashing lights means you're in kdb... but if you're in X, you're stuck >> there. Blindly typing "go" may get you going again. >> I put a fix in recently that prevents XFS from generating a transaction >> on a read-only snapshot, I'm guessing this is the same thing you're >> hitting. >> (if, for some reason (post-crash?) there are files with blocks past eof, >> xfs would try to clean those up, even if the underlying device is >> read-only, which will fail). >> You might try the very latest CVS code, or grab the next 1.2 prerelease >> that's available. >> Alternatively, if you tar up the "live" filesystem once, it will >> probably fix up the state of any files that may be causing this problem. >> -Eric >> On Thu, 2002-10-31 at 10:38, Greg Freemyer wrote: >> > I have a test machine which has started locking up when I run my backup >> script. >> > >> > The script creates a LVM snapshot for each of 3 LVs in turn and then >> uses xfsdump to back them up. >> > >> > After the lockup, nothing seems to work, but the keyboard lights are >> flashing. >> > >> > I'm running a pure CVS kernel from Sept. 6. >> > >> > My warn.log file has: >> > >> > Oct 20 01:15:22 TruStore1000 kernel: XFS mounting filesystem lvm(58,4) >> > Oct 20 01:15:28 TruStore1000 kernel: lvm - lvm_map: ll_rw_blk write for >> readonly LV /dev/TruStore-Data/config_snap >> > Oct 20 01:15:28 TruStore1000 kernel: I/O error in filesystem >> ("lvm(58,4)") meta-data dev 0x3a04 block 0x1a5c8 >> > Oct 20 01:15:28 TruStore1000 kernel: ("xlog_iodone") error 5 buf >> count 2560 >> > Oct 20 01:15:28 TruStore1000 kernel: xfs_force_shutdown(lvm(58,4),0x2) >> called from line 949 of file xfs_log.c. Return address = 0xc022b827 >> > Oct 20 01:15:28 TruStore1000 kernel: Log I/O Error Detected. Shutting >> down filesystem: lvm(58,4) >> > Oct 20 01:15:28 TruStore1000 kernel: Please umount the filesystem, and >> rectify the problem(s) >> > Oct 20 01:15:29 TruStore1000 kernel: XFS mounting filesystem lvm(58,3) >> > >> > The filesystem config_snap has already been deleted. >> > >> > I have not tried to reproduce this, but I suspect I can. It has >> happened twice so far. >> > >> > Is it likely a updated CVS kernel would fix this? >> > >> > Is there more data I can provide? >> > >> > Thanks, >> > Greg >> > ============= >> > Greg Freemyer >> > Internet Engineer >> > Deployment and Integration Specialist >> > Compaq ASE - Tru64 v4, v5 >> > Compaq Master ASE - SAN Architect >> > The Norcross Group >> > www.NorcrossGroup.com >> > >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. 651-683-3102 Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Oct 31 10:41:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 10:41:44 -0800 (PST) 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 g9VIffuR024346 for ; Thu, 31 Oct 2002 10:41:42 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA20502; Thu, 31 Oct 2002 12:42:19 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA36245; Thu, 31 Oct 2002 12:42:18 -0600 (CST) Subject: Re: re[2]: Lockup with LVM snapshot From: Eric Sandeen To: Greg Freemyer Cc: xfs mailing list In-Reply-To: <20021031183620.NQJW3311.imf25bis.bellsouth.net@TAZ2> References: <20021031183620.NQJW3311.imf25bis.bellsouth.net@TAZ2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Oct 2002 12:36:32 -0600 Message-Id: <1036089393.1562.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1441 X-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 Greg - Sorry, I didn't explain things very well, let me try to do better. :) XFS preallocates space at the end of the file, assuming that you'll probably use it, and things will be more efficient that way. When you close the file, this "extra" space is removed. Somehow, some files on your filesystem seem to be in the state where these preallocated blocks are still hanging out there past EOF. This isn't really a problem, everything is consistent, there are just more blocks than need to be there for the data. The next time you open & close the file, those blocks will be removed... ... unless you magically transport those files to a read-only device, as in the case of your snapshot. In that case, when you open & close the file, xfs was trying to clean up after itself, but the I/O failed (due to the readonly nature of the device) and the fs shut down. (And the kernel apparently oopsed after that... which is a different problem... :/) So, this new kernel will not try to clean up these past-EOF-blocks on a readonly device. The original files may still be on the "live" filesystem in this state, for whatever reason. They can be "fixed up" by opening & closing them, as tarring up the whole "live" filesystem would do. IOW, your new CVS kernel is only avoiding the problem on the readonly device; if you open & close the original files with either kernel, the problem will go away, and either kernel should work again with the snapshot. -Eric On Thu, 2002-10-31 at 12:34, Greg Freemyer wrote: > Thanks Eric, > > Current CVS kernel does indeed allow my backup to run. > > It is obvious that you guys have made a number of improvements in XFS/LVS integration in the last several months. > > I'm looking forward to the real 1.2 release. > > One question: do I still have an unusual data/meta-data problem on my LV that this kernel handles better Or did this kernel fix the on disk data itself and now I could go back to the old kernel? > > Greg -- 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 Thu Oct 31 11:41:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 11:42:04 -0800 (PST) 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 g9VJfwuR025828 for ; Thu, 31 Oct 2002 11:41:58 -0800 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g9VJgXD04818; Thu, 31 Oct 2002 20:42:33 +0100 Date: Thu, 31 Oct 2002 20:42:33 +0100 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: James Rich Cc: XFS mailing list Subject: Re: performance over multiple disks Message-ID: <20021031204233.Q30076@vestdata.no> References: 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: ; from james@chowhouse.com on Thu, Oct 31, 2002 at 10:49:47AM -0700 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g9VJgXD04818 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VJfxuR025829 X-archive-position: 1442 X-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 31, 2002 at 10:49:47AM -0700, James Rich wrote: > On another mailing list a debate arose about performance over a single > disk vs. multiple disks. It goes something like this: > > Suppose you have a 6 megabyte file stored on disk. Would it be read > faster if it were stored contiguously on a single disk or spread over > multiple (say 4) disks? > > It seems to me that as you get smaller it is faster for the single disk > case (remember that we are assuming the file is stored contiguously - not > spread all over the disk). At some size it seems natural that it would be > faster if the file were spread over multiple disks. Can anyone comment on > how XFS would perform? I don't have the equipment available to test this, > but I'm not too concerned with actual benchmark numbers. Mostly I'm just > wondering if I understand the filesystem correctly. If the file is stored on a single disk the read-time will be that of a single seek + file_size/transfer_rate (approxemately). If the file is spread over multiple disks the transfer-time will be reduced by a factor equal to the number of disks, but depending on read-ahead and other parameters the operation may happen serially or in parallell. If it happens in perfect parellell it will naturally be faster on multiple disks, but if it happens 100% serial order it will be slower because it requires more seeks. So, the most obvious answer would be that for files with several MBs of data the multiple-disk solution is faster, but it's not that simple. The problem is that this is based on the assumption that only a single operation is executed at once on the system - that's usually not the case on real-life systems. If you do the same calculations when multiple operations are going on at the same time you'll find that if you're reading 10 files from 10 disks it's going to be a lot quicker if the files are _not_ spread out. It's a common mistake to make, because if you run simple (single threaded) benchmarks the raid0 solution is the fastest one, but in real life it's not always so. -- Ragnar Kj鴕stad Big Storage From owner-linux-xfs@oss.sgi.com Thu Oct 31 11:46:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 11:46:21 -0800 (PST) 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 g9VJkJuR026281 for ; Thu, 31 Oct 2002 11:46:20 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 258D71EF069; Thu, 31 Oct 2002 11:47:03 -0800 (PST) Date: Thu, 31 Oct 2002 11:47:03 -0800 From: Chris Wedgwood To: Ragnar@f00f.org, Kj@f00f.org Cc: James Rich , XFS mailing list Subject: Re: performance over multiple disks Message-ID: <20021031194703.GC24676@tapu.f00f.org> References: <20021031204233.Q30076@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031204233.Q30076@vestdata.no> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1443 X-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 31, 2002 at 08:42:33PM +0100, Ragnar Kj?rstad wrote: > If you do the same calculations when multiple operations are going > on at the same time you'll find that if you're reading 10 files from > 10 disks it's going to be a lot quicker if the files are _not_ > spread out. More disks -> more heads -> lower average seek time. If you experiment with this, you'll find eads over multiple disks and stripping is almost *always* faster. RAID4/RAID5 will have slower writes obviously though. --cw From owner-linux-xfs@oss.sgi.com Thu Oct 31 12:01:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 12:01:10 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VK17uR027656 for ; Thu, 31 Oct 2002 12:01:07 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9VK1iA23079 for ; Thu, 31 Oct 2002 15:01:44 -0500 Message-ID: <3DC18C35.1030701@ksimachine.com> Date: Thu, 31 Oct 2002 15:01:57 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Thanks to everyone for the help. I have downloaded the SRPM files and have useable RPMs for all of the command files. But... Simon is correct, the kernel source from SGI for RedHat 2.4.18-17.7 will fail for i686. I can build using the SRPM from Redhat for the same kernel build (with out the SGI XFS bits). Am I correct in thinking that something is changed in the SGI-XFS source that is causing this problem? The files effected seem to be kernel-doc-2.4.18-17SGI_XFS_1.2pre2.i386.rpm and kernel-source-2.4.18-17SGI_XFS_1.2pre2.i386.rpm When I attemp to build from the SGI source it tells me I need "gcc >= 2.96-98". I currently have 2.96-85. This system is RedHat 7.1 with all updates except for 2.4.9-31SGI_XFS_1.1 kernel. RedHat network has a GCC 3.1 compiler suite for RedHat 7.3. Also the gcc levels exceed the needed one for both RedHat 7.2 and 7.3. Does anyone know if I can just do a upgrade to 3.1? -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Thu Oct 31 12:12:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 12:12:58 -0800 (PST) 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 g9VKCtuR028288 for ; Thu, 31 Oct 2002 12:12:56 -0800 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g9VKDWI06208; Thu, 31 Oct 2002 21:13:32 +0100 Date: Thu, 31 Oct 2002 21:13:32 +0100 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Chris Wedgwood Cc: Ragnar@f00f.org, Kj@f00f.org, James Rich , XFS mailing list Subject: Re: performance over multiple disks Message-ID: <20021031211332.U30076@vestdata.no> References: <20021031204233.Q30076@vestdata.no> <20021031194703.GC24676@tapu.f00f.org> 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: <20021031194703.GC24676@tapu.f00f.org>; from cw@f00f.org on Thu, Oct 31, 2002 at 11:47:03AM -0800 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g9VKDWI06208 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VKCuuR028289 X-archive-position: 1445 X-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 31, 2002 at 11:47:03AM -0800, Chris Wedgwood wrote: > On Thu, Oct 31, 2002 at 08:42:33PM +0100, Ragnar Kj?rstad wrote: > > If you do the same calculations when multiple operations are going > > on at the same time you'll find that if you're reading 10 files from > > 10 disks it's going to be a lot quicker if the files are _not_ > > spread out. > > More disks -> more heads -> lower average seek time. Obviously more heads is better, but spreading each individual file over multiple disks is not always faster - in particular when there are many requests executed at the same time. > If you experiment with this, you'll find eads over multiple disks and > stripping is almost *always* faster. RAID4/RAID5 will have slower > writes obviously though. "eads"? Try the following: Run a benchmark with 100 threads (or more) on a system with e.g. 10 drives. You will find that concatenating the drives is faster than using RAID0. All drives will be busy all the time in both setups, but with RAID0 you will have 10 seeks pr file instead of one, so total performance will be significantly lower. There are a number of external factors, like readahead, caching, blockdevice-elevator and so on that affect the result, so it's no easy to predict how big the difference will be. If the filesystem uses different layouts depending on the low-level storage system that will affect the result as well. How does XFS handle underlaying RAID0 compared to concatenated devices? -- Ragnar Kj鴕stad Big Storage From owner-linux-xfs@oss.sgi.com Thu Oct 31 12:16:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 12:16:59 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VKGguR028737 for ; Thu, 31 Oct 2002 12:16:50 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9VKHIA23752 for ; Thu, 31 Oct 2002 15:17:18 -0500 Message-ID: <3DC18FDB.3070501@ksimachine.com> Date: Thu, 31 Oct 2002 15:17:31 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030701@ksimachine.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Just a bit more infomation - Not only does the build fail on my system for i686 but also for i386. -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Thu Oct 31 12:27:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 12:28:00 -0800 (PST) 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 g9VKRwuR002171 for ; Thu, 31 Oct 2002 12:27:58 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 9CC431EF095; Thu, 31 Oct 2002 12:28:41 -0800 (PST) Date: Thu, 31 Oct 2002 12:28:41 -0800 From: Chris Wedgwood To: xfs@ragnark.vestdata.no Cc: James Rich , XFS mailing list Subject: Re: performance over multiple disks Message-ID: <20021031202841.GA25010@tapu.f00f.org> References: <20021031204233.Q30076@vestdata.no> <20021031194703.GC24676@tapu.f00f.org> <20021031211332.U30076@vestdata.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031211332.U30076@vestdata.no> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1447 X-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 31, 2002 at 09:13:32PM +0100, Ragnar Kj?rstad wrote: > If the filesystem uses different layouts depending on the low-level > storage system that will affect the result as well. How does XFS > handle underlaying RAID0 compared to concatenated devices? mkfs.xfs tries to be smart about MD devices and align things as a result of this. I'm not sure how well it works in practice though, I can test a little later... --cw P.S. You've got bogus 8-bit cruft in the headers... it's messing with mutt.. Arguably mutt should be fixed, but I'm not sure 8-bit From owner-linux-xfs@oss.sgi.com Thu Oct 31 13:13:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 13:13:57 -0800 (PST) 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 g9VLDpuR005355 for ; Thu, 31 Oct 2002 13:13:51 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA77065; Thu, 31 Oct 2002 15:14:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA19690; Thu, 31 Oct 2002 15:14:28 -0600 (CST) Subject: Re: Question about kernel update From: Eric Sandeen To: ksimach@ksimachine.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DC18FDB.3070501@ksimachine.com> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Oct 2002 15:08:41 -0600 Message-Id: <1036098522.1604.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1448 X-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 Joe - how does it fail? (Or is the failure the gcc version requirement you noted?) -Eric On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > Just a bit more infomation - Not only does the build fail on my system > for i686 but also for i386. > > -- > Joseph St.Clair - KSI Machine & Engineering > > > -- 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 Thu Oct 31 13:47:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 13:47:57 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VLlsuR009149 for ; Thu, 31 Oct 2002 13:47:55 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g9VLmbL28005; Thu, 31 Oct 2002 16:48:37 -0500 Message-ID: <3DC1A543.80606@ksimachine.com> Date: Thu, 31 Oct 2002 16:48:51 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Yes, when I attempt to build from the SGI SRPM it fails due to the gcc version. I have just downloaded gcc-3.1 from the RedHat site. It seems that the only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. So now I am downloading the gcc from RedHat 7.2, check its dependencies, update with that and then update to 3.1. I don't know if this will break anything but as far as I know it should be ok. I won't get to check this out until tomorrow. Eric Sandeen wrote: >Joe - how does it fail? (Or is the failure the gcc version requirement >you noted?) > >-Eric > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > >>Just a bit more infomation - Not only does the build fail on my system >>for i686 but also for i386. >> >>-- >>Joseph St.Clair - KSI Machine & Engineering >> >> >> >> >> -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Thu Oct 31 14:30:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 14:30:30 -0800 (PST) Received: from imf23bis.bellsouth.net (mail225.mail.bellsouth.net [205.152.58.195]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VMURuR010284 for ; Thu, 31 Oct 2002 14:30:27 -0800 Received: from TAZ2 ([66.156.1.8]) by imf23bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021031223250.DRDX3370.imf23bis.bellsouth.net@TAZ2>; Thu, 31 Oct 2002 17:32:50 -0500 Date: Thu, 31 Oct 2002 17:30:58 -0500 From: Greg Freemyer Subject: re: performance over multiple disks To: James Rich , XFS mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021031223250.DRDX3370.imf23bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VMUSuR010285 X-archive-position: 1450 X-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 >> On another mailing list a debate arose about performance over a single >> disk vs. multiple disks. It goes something like this: >> Suppose you have a 6 megabyte file stored on disk. Would it be read >> faster if it were stored contiguously on a single disk or spread over >> multiple (say 4) disks? >> It seems to me that as you get smaller it is faster for the single disk >> case (remember that we are assuming the file is stored contiguously - not >> spread all over the disk). At some size it seems natural that it would be >> faster if the file were spread over multiple disks. Can anyone comment on >> how XFS would perform? I don't have the equipment available to test this, >> but I'm not too concerned with actual benchmark numbers. Mostly I'm just >> wondering if I understand the filesystem correctly. >> James Rich James, I don't fully understand the logic, but I have a Compaq Storage Performance guide in front of me. For high data rate applications such as yours it recommends a stripe width (SW) of 17 sectors. It says that you want this small to get the spindles working in parallel, but if you go below 17, you start getting excessive overhead. i.e. 17 sectors of contiguous data per drive. For high request rate, it recommends the below stripe widths (SW): highly localized requests: SW = 10x avg. transfer size highly non-localized requests: SW = 20x avg. transfer size unknown localization: SW = 15x avg. transfer size. For all cases, they recommend your SW be a prime number. So the above just get you in the neighborhood and you select the closest prime number. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Oct 31 14:41:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 14:41:41 -0800 (PST) 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 g9VMfcuR010962 for ; Thu, 31 Oct 2002 14:41:39 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA17942; Thu, 31 Oct 2002 16:42:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA73326; Thu, 31 Oct 2002 16:42:16 -0600 (CST) Subject: Re: Question about kernel update From: Eric Sandeen To: ksimach@ksimachine.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DC1A543.80606@ksimachine.com> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 Oct 2002 16:36:29 -0600 Message-Id: <1036103789.1657.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1451 X-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 Ok, I'm pretty confused by this. :) The only difference I see between the "stock" kernel spec files for 17.7.x and 17.8.0 is: -%define release 17.7.x +%define release 17.8.0 (i.e. no gcc differences) and the only differences between the 17.?.? Red Hat specfiles, and our specfile, (aside from the release name) are the XFS patches. I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're supposed to rebuild it on 7.1, or why you seem to be able to. So I'm stumped. :) -Eric On Thu, 2002-10-31 at 15:48, Joe St.Clair wrote: > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > version. > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > update with that and then update to 3.1. > > I don't know if this will break anything but as far as I know it should > be ok. > > I won't get to check this out until tomorrow. > > > Eric Sandeen wrote: > > >Joe - how does it fail? (Or is the failure the gcc version requirement > >you noted?) > > > >-Eric > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > >>Just a bit more infomation - Not only does the build fail on my system > >>for i686 but also for i386. > >> > >>-- > >>Joseph St.Clair - KSI Machine & Engineering > >> > >> > >> > >> > >> > > > -- > Joseph St.Clair - KSI Machine & Engineering > > -- 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 Thu Oct 31 15:08:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 15:08:25 -0800 (PST) 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 g9VN8KuR012016 for ; Thu, 31 Oct 2002 15:08:21 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 187OQu-0008HW-00; Thu, 31 Oct 2002 23:09:00 +0000 Date: Thu, 31 Oct 2002 23:09:00 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: Question about kernel update Message-ID: <20021031230900.A31751@infradead.org> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1036103789.1657.23.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Oct 31, 2002 at 04:36:29PM -0600 X-archive-position: 1452 X-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 31, 2002 at 04:36:29PM -0600, Eric Sandeen wrote: > I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, > but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're > supposed to rebuild it on 7.1, or why you seem to be able to. > > So I'm stumped. :) It's most likey a gcc bug. Could those who saw it with the latest errata gcc (i.e. not with the out-of-date one like me) fill a bugreport at redhat's bugzilla (for gcc, not the kernel! :)) and post the url to the bug here? From owner-linux-xfs@oss.sgi.com Thu Oct 31 15:13:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 15:13:58 -0800 (PST) Received: from imf06bis.bellsouth.net (mail106.mail.bellsouth.net [205.152.58.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VNDtuR012512 for ; Thu, 31 Oct 2002 15:13:55 -0800 Received: from TAZ2 ([66.156.1.8]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021031231618.BLTE20501.imf06bis.bellsouth.net@TAZ2>; Thu, 31 Oct 2002 18:16:18 -0500 Date: Thu, 31 Oct 2002 18:14:26 -0500 From: Greg Freemyer Subject: re[4]: Lockup with LVM snapshot To: Eric Sandeen cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021031231618.BLTE20501.imf06bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9VNDtuR012513 X-archive-position: 1453 X-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 Eric, Thanks for the detailed explanation. I have just done a xfsdump level 0, so everything should be clean now. Greg >> Hi Greg - >> Sorry, I didn't explain things very well, let me try to do better. :) >> XFS preallocates space at the end of the file, assuming that you'll >> probably use it, and things will be more efficient that way. When you >> close the file, this "extra" space is removed. >> Somehow, some files on your filesystem seem to be in the state where >> these preallocated blocks are still hanging out there past EOF. This >> isn't really a problem, everything is consistent, there are just more >> blocks than need to be there for the data. The next time you open & >> close the file, those blocks will be removed... >> ... unless you magically transport those files to a read-only device, as >> in the case of your snapshot. In that case, when you open & close the >> file, xfs was trying to clean up after itself, but the I/O failed (due >> to the readonly nature of the device) and the fs shut down. (And the >> kernel apparently oopsed after that... which is a different problem... >> :/) >> So, this new kernel will not try to clean up these past-EOF-blocks on a >> readonly device. >> The original files may still be on the "live" filesystem in this state, >> for whatever reason. They can be "fixed up" by opening & closing them, >> as tarring up the whole "live" filesystem would do. >> IOW, your new CVS kernel is only avoiding the problem on the readonly >> device; if you open & close the original files with either kernel, the >> problem will go away, and either kernel should work again with the >> snapshot. >> -Eric >> On Thu, 2002-10-31 at 12:34, Greg Freemyer wrote: >> > Thanks Eric, >> > >> > Current CVS kernel does indeed allow my backup to run. >> > >> > It is obvious that you guys have made a number of improvements in >> XFS/LVS integration in the last several months. >> > >> > I'm looking forward to the real 1.2 release. >> > >> > One question: do I still have an unusual data/meta-data problem on my LV >> that this kernel handles better Or did this kernel fix the on disk data >> itself and now I could go back to the old kernel? >> > >> > Greg >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. 651-683-3102 Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Oct 31 15:35:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 15:35:28 -0800 (PST) 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 g9VNZOuR016775 for ; Thu, 31 Oct 2002 15:35:24 -0800 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 PAA02769 for ; Thu, 31 Oct 2002 15:36:07 -0800 (PST) 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 KAA26679; Fri, 1 Nov 2002 10:34:48 +1100 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 g9VMXnI5000822; Fri, 1 Nov 2002 09:33:49 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g9VMXmWE000820; Fri, 1 Nov 2002 09:33:48 +1100 Date: Fri, 1 Nov 2002 09:33:48 +1100 From: Nathan Scott To: Murthy Kambhampaty Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: "xfsprogs updates" folow-up to TAKE - userspace updates Message-ID: <20021031223348.GA767@frodo> References: <2D92FEBFD3BE1346A6C397223A8DD3FC09205E@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC09205E@THOR.goeci.com> User-Agent: Mutt/1.4i X-archive-position: 1454 X-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 Thu, Oct 31, 2002 at 10:18:00AM -0500, Murthy Kambhampaty wrote: > Nathan, it seems like a good time to catch up to the CVS kernel, but I'd > like to wait out the full sync up of xfsprogs to recent kernel changes. > Could you put in a comment against the patches that "complete" the sync up. > I recommend you take the current xfsprogs. There is nothing coming from the remaining sync up that fixes problems (that bit is merged) and I'm not sure when the remaining piece will be merged back, it's not a real high a priority atm. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 31 18:52:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 18:52:17 -0800 (PST) Received: from ooo.no (fb171157.ot.FreeBit.NE.JP [61.203.171.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA12oauR020689 for ; Thu, 31 Oct 2002 18:51:13 -0800 Received: from wing-cilnjn2j6v ([192.168.0.2]) by ooo.no (8.9.3+3.2W/3.7W) with SMTP id LAA19522; Fri, 1 Nov 2002 11:51:32 +0900 Message-Id: <200211010251.LAA19522@ooo.no> From: =?iso-2022-jp?B?Y21haWwxMWpw?= To: =?iso-2022-jp?B?bWVsbWVs?=@ooo.no Reply-To: cmail11jp@yahoo.co.jp Date: Fri, 01 Nov 2002 11:49:46 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cmail11jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <憲怣幰> 揹巕儊乕儖峀崘幮 崱屻丄峀崘傪偛婓朷偟側偄曽偼偙偙傊 (昁偢杮暥偵偁側偨偺儊乕儖傾僪儗僗偺傒傪偍彂偒壓偝偄乯 king2@mvb.biglobe.ne.jp 儊乕儖傾僪儗僗傪偛婰擖偟偰偔偩偝偄丅 仹104-0061 搶嫗搒拞墰嬫嬧嵗8-19-3 戞2僂僀儞僌價儖丂3F 儊乕儖儅僈僕儞敪峴 TEL丂03-3544-6222 FAX丂03-3544-6218 =============================================================== 栤戣彜昳偽偐傝廤傔傑偟偨偺偱丄徚偝傟傞嫲傟偑偁傝傑偡偺偱 偍怽崬傒偼偍憗傔偵両 =============================================================== 仭丂夛堳惂儘儕乕僞僋儔僽丂仭 俢倁俢丒價僨僆2500墌偐傜 僴僀僋僆儕僥傿夋幙偱偺斕攧儅僯傾僢僋側塮憸偺悢乆 傑偢偼僇僞儘僌惪媮偍懸偪偟偰偍傝傑偡乮嬊棷傔偱偺惪媮壜擻乯 偍庤尦偵偍撏偔晻摏偵偼丄偍媞條偺偍柤慜偺傒両摉幮柤偼堦愗擖傝傑偣傫丅 僇僞儘僌傪偍尒偰丄偍怽偟崬傒偔偩偝偄丅 柍椏僇僞儘僌 http://www97.sakura.ne.jp/~kong/roriclub/ http://koukoku.idyl.net/roriclub/ http://koukoku1.netfirms.com/roriclub/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂夛堳惂儘儕乕僞僋儔僽 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭SEX僼儗儞僪曞廤仭 恀寱偵SEX僼儗儞僪傪扵偟偰偄傞恖偩偗廤崌両 慡崙偳偙偱傕嬤偔偺恖傪僾儘僼傿乕儖晅偱偡偖徯夘丅 庒偄恖偐傜弉擭傑偱偄偭傁偄偄傞傛! 僟儞僫偵撪弿偺H傪妝偟傕偆両 http://www97.sakura.ne.jp/~kong/sex/ http://koukoku.idyl.net/sex/ http://koukoku1.netfirms.com/sex/ 儗儌儞僋儔僽 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭傕傕偑偼偠偗偰傇偳偆偑備傟傞仭 偟偠傒偲傕傕偺僐儔儃儗乕僔儑儞 儘儕乕僞價僨僆乮俢倁俢乯愱栧 偄偮傑偱塩嬈偱偒傞偐傢偐傝傑偣傫 偛拲暥偼偍憗傔偵両 http://www97.sakura.ne.jp/~kong/roridvd/rori/ http://koukoku.idyl.net/roridvd/rori/ http://koukoku1.netfirms.com/roridvd/rori/ 嶌昳椺 彮彈揱愢丂柤屆壆抍抧9丂彮彈偺摴憪 側偳側偳132嶌昳丅岲昡敪攧拞両 丂(^-^)/~儘儕楩棙儉僩乕 丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵丵 仭丂俽俵僷乕僩僫乕徯夘懄擔丂仭 俽俵僷乕僩僫乕懄擔徯夘丅 墖彆傗SM僋儔僽偲偼堘偄丄俽俵垽岲幰偩偗偑廤偆夛丅 慡崙偱偛徯夘偱偒傑偡丅 偁側偨偺僾儗僀偵偁傢偣偰懄擔徯夘丅 僾儗僀戙嬥偼堦愗偐偐傝傑偣傫丅 擭楊偼20嵨埲忋丅 http://www97.sakura.ne.jp/~kong/sm/ http://koukoku.idyl.net/sm/ http://koukoku1.netfirms.com/sm/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂俽俵僋儔僽 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂恖宍巘偑嶌偭偨寙嶌昳丂仭 書偒偟傔偨偔側傞傛偆側偍恖宍偝傫偑嶌傟傑偟偨丅 敋敪揑戝僸僢僩彜昳両 悢偵惂尷偑偁傞偨傔丄偍怽偟崬傒偼偍憗傔偵両 仚嬊晹傑偱杮暔偦偭偔傝偵惂嶌偟偨偨傔丄揦摢斕攧偱偒傑偣傫丅 http://www97.sakura.ne.jp/~kong/dachi/dollc/ http://koukoku.idyl.net/dachi/dollc/ http://koukoku1.netfirms.com/dachi/dollc/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂恖宍巘媨愳僨僓僀儞 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂媡墖彆岎嵺偔傜傇丂仭 慺揋側抝惈偲挬傑偱擇恖丒丒丒丅 慺揋側抝惈傪崱偡偖婱彈偺尦傊岦偐傢偣傑偡丅 慡崙僱僢僩儚乕僋偱偡偖偵徯夘俷俲丅 庒偄彈惈傕墦椂偟側偄偱梀傃傑偔傠偆両 侾夞尷傝丄挿婜丄壗偱傕偁傝丅 侓彈惈偵桪偟偔偱偒傞抝惈僗僞僢僼傕摨帪曞廤拞侓 http://www97.sakura.ne.jp/~kong/enjyo/ http://koukoku.idyl.net/enjyo/ http://koukoku1.netfirms.com/enjyo/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂媡墖彆夛 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂儅儕僼傽僫偺庬丂仭 儅儕僼傽僫偑偨傑傜側偔岲偒側恖丄偳偆偧丄偙偙傊丅 偁傇側偄偔偡傝偺忣曬傕庤偵擖傞傛両 乽愨懳偵埆梡偟側偄偱偔偩偝偄丅乿 http://www97.sakura.ne.jp/~kong/mari/ http://koukoku.idyl.net/mari/ http://koukoku1.netfirms.com/mari/ 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂怷丂惓抝 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗 仭丂怴憰奐揦両寖埨僙乕儖丂仭 AV.DVD寖埨僙乕儖 懠揦偱偼庤偵擖傜側偄傕偺偽偐偟ゥゥゥ 埲慜偺傛偆偵丄傛傠偟偔偍婅偄偟傑偡丅 懠揦偵晧偗偢寖埨椏嬥両 http://www97.sakura.ne.jp/~kong/pink/ http://koukoku.idyl.net/pink/ http://koukoku1.netfirms.com/pink/ 丂丂丂 丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂丂旤彮彈僋儔僽 乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗乗