From owner-linux-xfs@oss.sgi.com Sun Apr 1 08:50:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31FoYG12643 for linux-xfs-outgoing; Sun, 1 Apr 2001 08:50:34 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31FoXM12640 for ; Sun, 1 Apr 2001 08:50:33 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31FnfiP019486; Sun, 1 Apr 2001 10:49:42 -0500 (CDT) Message-ID: <3AC74E10.9103DA5@thebarn.com> Date: Sun, 01 Apr 2001 10:49:36 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jens Axboe CC: Robin Humble , linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch References: <200104010616.GAA28360@groucho.maths.monash.edu.au> <3AC6D32C.122FF4BE@thebarn.com> <20010401090939.B26093@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jens Axboe wrote: > On Sun, Apr 01 2001, Russell Cattelan wrote: > > Robin Humble wrote: > > > > > I downloaded the xfs and xfs-core patches and applied them both to a > > > straight linux-2.4.3.tar.bz - it all builds just fine except for the > > > loop module: > > > > Oppps my fault I probably forgot to add loop.c to patch gen script. > > > > Try this is should fix the build. I'll redo the patch it the morning. > > It would not appear to be enough: > > > > loop.c: In function `loop_init': > > > loop.c:983: warning: passing arg 2 of `blk_queue_make_request_Rdfd55e90' > > I'll bet you that you also didn't change the loop_make_request prototype. Yes your right I did miss that also. Fixed. Thanks. > > > -- > Jens Axboe -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Apr 1 09:12:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31GCtv13073 for linux-xfs-outgoing; Sun, 1 Apr 2001 09:12:55 -0700 Received: from fencepost.gnu.org (we-refuse-to-spy-on-our-users@fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31GCtM13070 for ; Sun, 1 Apr 2001 09:12:55 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 3.16 #1 (Debian)) id 14jkTA-0001SM-00 for ; Sun, 01 Apr 2001 12:12:48 -0400 Date: Sun, 1 Apr 2001 12:12:48 -0400 From: Lennert Buytenhek To: linux-xfs@oss.sgi.com Subject: O_DIRECT buglet Message-ID: <20010401121248.A14579@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (Not on the list, please CC on replies) Hi, Doing O_DIRECT I/O to a buffer which is not on an appropriate block boundary seem to fail with return code 22 instead of -22 (EINVAL). This is on 2.4.2 with an XFS tree checkout from 20010329. tia, Lennert -- test.c #include #include #include #include #include #include #define O_DIRECT 040000 /* direct disk access hint */ int main() { char buf[16384]; int fd; char *p; p = (char *)((((unsigned long)buf) + 8191) & ~8191L); fd = open("blah", O_CREAT | O_RDWR | O_DIRECT); printf("write returns %i\n", write(fd, buf, 8192)); printf("write returns %i\n", write(fd, p, 1)); return 0; } -- actual output [buytenh@mara test]$ ./test write returns 22 write returns 22 From owner-linux-xfs@oss.sgi.com Sun Apr 1 09:47:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31GlSF13753 for linux-xfs-outgoing; Sun, 1 Apr 2001 09:47:28 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31GlRM13749 for ; Sun, 1 Apr 2001 09:47:27 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31GlLiP026026; Sun, 1 Apr 2001 11:47:25 -0500 (CDT) Message-ID: <3AC75B93.19AB5A8C@thebarn.com> Date: Sun, 01 Apr 2001 11:47:15 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Lennert Buytenhek CC: linux-xfs@oss.sgi.com Subject: Re: O_DIRECT buglet References: <20010401121248.A14579@gnu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lennert Buytenhek wrote: > (Not on the list, please CC on replies) page aligned memory is necessary This isn't complete obviously but it is the basic code to get a buffer that starts on a page boundary. struct dioattr finfo; ioctl(fd, XFS_IOC_DIOINFO, &finfo) buf = (char *)malloc( +finfo.d_mem); if( ((long)buf % finfo.d_mem != 0) ) { buf += finfo.d_mem - ((long)buf % finfo.d_mem); } > > > Hi, > > Doing O_DIRECT I/O to a buffer which is not on an appropriate block boundary > seem to fail with return code 22 instead of -22 (EINVAL). This is on 2.4.2 > with an XFS tree checkout from 20010329. > > tia, > Lennert > > -- test.c > #include > #include > #include > #include > #include > #include > > #define O_DIRECT 040000 /* direct disk access hint */ > > int main() > { > char buf[16384]; > int fd; > char *p; > > p = (char *)((((unsigned long)buf) + 8191) & ~8191L); > fd = open("blah", O_CREAT | O_RDWR | O_DIRECT); > > printf("write returns %i\n", write(fd, buf, 8192)); > printf("write returns %i\n", write(fd, p, 1)); > > return 0; > } > -- actual output > [buytenh@mara test]$ ./test > write returns 22 > write returns 22 -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Apr 1 09:50:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Go5l13827 for linux-xfs-outgoing; Sun, 1 Apr 2001 09:50:05 -0700 Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f31Go4M13823 for ; Sun, 1 Apr 2001 09:50:04 -0700 Received: (qmail 18478 invoked by uid 8); 1 Apr 2001 16:50:02 -0000 From: thomas graichen Reply-To: thomas graichen X-Newsgroups: spoiled.linux.sgi.xfs Subject: any know gdbm problems on XFS? Date: Sun, 1 Apr 2001 18:43:08 +0200 Organization: spoiled dot org Lines: 26 Distribution: local Message-ID: Reply-To: thomas graichen X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2-XFS (i586)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk this is something which has to be investigated further first by me but i'd like to ask around here too ... are there any issues known regarding gdbm db's on XFS filesystems? (i assume no :-) the reason i ask is that i had some trouble with my little offline newsserver i use here for reading the mailinglists - noffle - it puts all the articles it stores into an gdbm database which is on this machine here on an XFS filesystem ... it worked fine here for some time but then noffle started crashing on more and more groups and debugging it did not really bring up any useful results ... i then contacted the author of noffle and he said that there are some issues with noffle running on reiserfs - so i was thinking about possible problems on XFS ... ok - to find out what is the reason for the most probably corrupted gdbm database i now run the noffle spools on an ext2 filesystem - i hope to know more within the next days ... so - no proven problem with XFS for now - i'll mail again if it works on ext2 (because then it would be an XFS problem ...) t -- thomas graichen ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery From owner-linux-xfs@oss.sgi.com Sun Apr 1 09:56:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Gu7s13950 for linux-xfs-outgoing; Sun, 1 Apr 2001 09:56:07 -0700 Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31Gu6M13947 for ; Sun, 1 Apr 2001 09:56:06 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 3.16 #1 (Debian)) id 14jl8z-0004EU-00; Sun, 01 Apr 2001 12:56:01 -0400 Date: Sun, 1 Apr 2001 12:56:01 -0400 From: Lennert Buytenhek To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: O_DIRECT buglet Message-ID: <20010401125601.A15276@gnu.org> References: <20010401121248.A14579@gnu.org> <3AC75B93.19AB5A8C@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AC75B93.19AB5A8C@thebarn.com>; from cattelan@thebarn.com on Sun, Apr 01, 2001 at 11:47:15AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 01, 2001 at 11:47:15AM -0500, Russell Cattelan wrote: > Lennert Buytenhek wrote: > > > (Not on the list, please CC on replies) > > page aligned memory is necessary Doh. I know how O_DIRECT works, thank you. Please reread my original mail. > This isn't complete obviously but it is the basic code > to get a buffer that starts on a page boundary. > > > struct dioattr finfo; > ioctl(fd, XFS_IOC_DIOINFO, &finfo) > buf = (char *)malloc( +finfo.d_mem); > if( ((long)buf % finfo.d_mem != 0) ) { > buf += finfo.d_mem - ((long)buf % finfo.d_mem); > } > > > > > > > > > > Hi, > > > > Doing O_DIRECT I/O to a buffer which is not on an appropriate block boundary > > seem to fail with return code 22 instead of -22 (EINVAL). This is on 2.4.2 > > with an XFS tree checkout from 20010329. > > > > tia, > > Lennert > > > > -- test.c > > #include > > #include > > #include > > #include > > #include > > #include > > > > #define O_DIRECT 040000 /* direct disk access hint */ > > > > int main() > > { > > char buf[16384]; > > int fd; > > char *p; > > > > p = (char *)((((unsigned long)buf) + 8191) & ~8191L); > > fd = open("blah", O_CREAT | O_RDWR | O_DIRECT); > > > > printf("write returns %i\n", write(fd, buf, 8192)); > > printf("write returns %i\n", write(fd, p, 1)); > > > > return 0; > > } > > -- actual output > > [buytenh@mara test]$ ./test > > write returns 22 > > write returns 22 > > -- > Russell Cattelan > cattelan@thebarn.com > > > From owner-linux-xfs@oss.sgi.com Sun Apr 1 09:56:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31GueS13961 for linux-xfs-outgoing; Sun, 1 Apr 2001 09:56:40 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31GudM13958 for ; Sun, 1 Apr 2001 09:56:39 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31GtmiP028066; Sun, 1 Apr 2001 11:55:48 -0500 (CDT) Message-ID: <3AC75D8E.564BD6A9@thebarn.com> Date: Sun, 01 Apr 2001 11:55:43 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jens Axboe , Robin Humble , linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch References: <200104010616.GAA28360@groucho.maths.monash.edu.au> <3AC6D32C.122FF4BE@thebarn.com> <20010401090939.B26093@suse.de> <3AC74E10.9103DA5@thebarn.com> Content-Type: multipart/mixed; boundary="------------BAC880D26ECBDD90583162BF" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------BAC880D26ECBDD90583162BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok the patch has been updated. Also fixed make_request_fn functions in lvm.c and md.c which was producing the same warnings as loop. For documentation purposed I'm including the script that is used to produce the patch, it give a good roadmap of the XFS changes to the core linux files. Russell Cattelan cattelan@thebarn.com --------------BAC880D26ECBDD90583162BF Content-Type: application/x-perl; name="XFSgenPatch2_4_3.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="XFSgenPatch2_4_3.pl" #!/usr/bin/perl use Data::Dumper; use POSIX qw(strftime); $date = strftime "%m%d%Y", localtime; $corePatch = "linux-2.4.3-core-xfs-".$date.".patch"; $xfsPatch = "linux-2.4.3-xfs-".$date.".patch"; $baseLinux = "/export/extra/lxfs-cvs/linux-2.4.3"; @xfs_dir = ( "fs/xfs_support", "fs/xfs", "fs/pagebuf", "fs/ext_attr.c", "fs/noposix_acl.c", "fs/posix_acl.c", "Documentation/filesystems/xfs.txt", "include/linux/xfs_fs_i.h", "include/linux/page_buf.h", "include/linux/vnode.h", "include/linux/xfs_fs_sb.h", "include/linux/xfs_fs.h", "include/linux/avl.h", "include/linux/page_buf_trace.h", "include/linux/dmapi_kern.h", "include/linux/dmapi.h", "include/linux/behavior.h", "include/linux/grio.h", "include/linux/acl.h", "include/linux/attributes.h", "include/linux/xqm.h" ); @file = ( "Makefile", "Rules.make", "fs/Makefile", #Add xfs and pagebuf directories "fs/buffer.c", # Delayed buffers "fs/inode.c", #ihold4 "fs/filesystems.c", #init_xfs call "fs/dquot.c", #XFS quota changes "fs/Config.in", #xfs config options "init/main.c", #pagebuf init call "kernel/ksyms.c", #extra symbol exports "mm/filemap.c", #Some tweaks from Rik Van Reil, pagebuf hooks "mm/vmscan.c", #GFP_PAGE_IO support from Marcelo "mm/slab.c", #kmem_cache_zalloc "mm/vmalloc.c", # kiobuf mount flag, blksetsize ioctl, extra buffer flags, xfs includes and # additions to inode and super block. ops vector changes for pagebuf and xfs. "include/linux/fs.h", "include/linux/sysctl.h", # pagebuf sysctl changes "include/linux/pagemap.h", #Added new function prototypes "include/linux/mm.h", #DelallocPage macro, GFP_PAGE_IO define "include/linux/slab.h", #PAGE_IO defines, kmem_cache_zalloc define "include/linux/vmalloc.h", "arch/sparc64/kernel/ioctl32.c", "arch/mips64/kernel/ioctl32.c", "drivers/scsi/sd.c", "drivers/block/blkpg.c", "drivers/md/md.c", # LVM files "drivers/md/lvm-internal.h", "drivers/md/lvm-fs.c", "include/linux/lvm.h", "drivers/md/lvm.c", "drivers/md/Makefile", "drivers/md/lvm-snap.c", # end LVM files "fs/partitions/check.c", # Sar additions "include/linux/genhd.h", # Sar addtions "Documentation/filesystems/00-INDEX", #XFS documentation "Documentation/Configure.help"); #Config option help #DMAPI specific changes (14 files) @dmapi = ( "include/asm-i386/fcntl.h", "include/asm-mips/fcntl.h", "include/asm-alpha/fcntl.h", "include/asm-m68k/fcntl.h", "include/asm-sparc/fcntl.h", "include/asm-ppc/fcntl.h", "include/asm-sparc64/fcntl.h", "include/asm-arm/fcntl.h", "include/asm-sh/fcntl.h", "include/asm-ia64/fcntl.h", "include/asm-mips64/fcntl.h", "include/asm-s390/fcntl.h", #O_INVISIBLE definition "include/linux/miscdevice.h", #DMAPI device definition - should be submitted to device number maintainer "fs/super.c"); #dmapi code in mount path #KIOBUF I/O specific changes (17 files) @kio = ( "fs/iobuf.c", # "fs/buffer.c", #kiobuf bounce page support # "drivers/scsi/sd.c", "drivers/block/rd.c", "drivers/block/loop.c", # change params to generic_make_request "drivers/scsi/scsi_merge.c", "drivers/scsi/scsi_lib.c", "drivers/ide/ide-disk.c", "drivers/ide/ide-dma.c", "drivers/ide/ide.c", "drivers/md/raid1.c", "drivers/md/raid5.c", #Kiobuf I/O support "drivers/char/raw.c", #Kiobuf I/O support for Raw I/O "include/linux/blkdev.h", #kiobuf I/O function definition changes and require structure changes "include/linux/major.h", # kiobuf I/O added macros "include/linux/ide.h", #Kiobuf I/O ide structure changes "drivers/block/ll_rw_blk.c", "drivers/block/elevator.c", #kiobuf I/O changes "include/linux/iobuf.h"); #Kiobuf I/O changes for bounce buffers @attr = ( # "fs/Makefile", #add posix_acl code and extended attribute code # "fs/Config.in", #posix acl config options "include/asm-i386/unistd.h", "include/asm-ia64/unistd.h", "arch/i386/kernel/entry.S", "arch/ia64/ia32/ia32_entry.S", "arch/ia64/kernel/entry.S", "arch/ia64/kernel/ivt.S"); #extended attribute and acl syscall numbers @genfix = ( "fs/namei.c", #nested symlink fix - is this real? If it is lets get it submitted "mm/memory.c"); #kiovec locking fixes - needed for generic pagebuf code push (@full, \@genfix); push (@full, \@attr); push (@full, \@kio); push (@full, \@dmapi); push (@full, \@file); #push (@full, \@xfs_dir); foreach $dir (@full){ push(@fullList,@{$dir}); } open(CORE,"> $corePatch") || die "$corePatch $!\n"; foreach $dir (sort(@fullList)){ if ( -f "$baseLinux/linux/$dir" ){ $cmd = "diff -rNu $baseLinux/linux/$dir linux/$dir"; } else { $cmd = "diff -rNu /dev/null linux/$dir"; } print STDERR "$cmd\n"; open (DIFF, "$cmd |") || die "$cmd $!\n"; while (){ print CORE $_; } close(DIFF); } close(CORE); newfile(); exit; sub newfile { open(XFS,"> $xfsPatch") || die "$xfsPatch $!\n"; foreach $dir (@xfs_dir) { # $cmd = "diff -rNu $baseLinux/linux/$dir linux/$dir"; if (! -d "/tmp/null") { mkdir ("/tmp/null",0755) || die "/tmp/null $!\n"; } if (-d "linux/$dir" ) { $cmd = "diff -rNu /tmp/null linux/$dir"; } elsif (-f "linux/$dir" ) { $cmd = "diff -rNu /dev/null linux/$dir"; } print STDERR "$cmd\n"; open (DIFF, "$cmd |") || die "$cmd $!\n"; while (){ print XFS $_; } close(DIFF); } } --------------BAC880D26ECBDD90583162BF-- From owner-linux-xfs@oss.sgi.com Sun Apr 1 10:00:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31H00M14029 for linux-xfs-outgoing; Sun, 1 Apr 2001 10:00:00 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31GxxM14016 for ; Sun, 1 Apr 2001 10:00:00 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31GxwiP029600; Sun, 1 Apr 2001 11:59:58 -0500 (CDT) Message-ID: <3AC75E89.7AFE485A@thebarn.com> Date: Sun, 01 Apr 2001 11:59:53 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Lennert Buytenhek CC: linux-xfs@oss.sgi.com Subject: Re: O_DIRECT buglet References: <20010401121248.A14579@gnu.org> <3AC75B93.19AB5A8C@thebarn.com> <20010401125601.A15276@gnu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lennert Buytenhek wrote: > On Sun, Apr 01, 2001 at 11:47:15AM -0500, Russell Cattelan wrote: > > > Lennert Buytenhek wrote: > > > > > (Not on the list, please CC on replies) > > > > page aligned memory is necessary > > Doh. I know how O_DIRECT works, thank you. Please reread my original mail. Arggh terribly sorry... guess I didn't have enough coffee yet this morning. Guess we'll have to track down the return that isn't fliping the sign. Thanks. > > > > This isn't complete obviously but it is the basic code > > to get a buffer that starts on a page boundary. > > > > > > struct dioattr finfo; > > ioctl(fd, XFS_IOC_DIOINFO, &finfo) > > buf = (char *)malloc( +finfo.d_mem); > > if( ((long)buf % finfo.d_mem != 0) ) { > > buf += finfo.d_mem - ((long)buf % finfo.d_mem); > > } > > > > > > > > > > > > > > > > > Hi, > > > > > > Doing O_DIRECT I/O to a buffer which is not on an appropriate block boundary > > > seem to fail with return code 22 instead of -22 (EINVAL). This is on 2.4.2 > > > with an XFS tree checkout from 20010329. > > > > > > tia, > > > Lennert > > > > > > -- test.c > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > > > > #define O_DIRECT 040000 /* direct disk access hint */ > > > > > > int main() > > > { > > > char buf[16384]; > > > int fd; > > > char *p; > > > > > > p = (char *)((((unsigned long)buf) + 8191) & ~8191L); > > > fd = open("blah", O_CREAT | O_RDWR | O_DIRECT); > > > > > > printf("write returns %i\n", write(fd, buf, 8192)); > > > printf("write returns %i\n", write(fd, p, 1)); > > > > > > return 0; > > > } > > > -- actual output > > > [buytenh@mara test]$ ./test > > > write returns 22 > > > write returns 22 > > > > -- > > Russell Cattelan > > cattelan@thebarn.com > > > > > > -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Apr 1 10:59:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31HxJg15329 for linux-xfs-outgoing; Sun, 1 Apr 2001 10:59:19 -0700 Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31HxHM15325 for ; Sun, 1 Apr 2001 10:59:17 -0700 Received: from ip099.pool-05.cyb.it (ip099.pool-05.cyb.it [195.191.4.100]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f31Hwsu20977 for ; Sun, 1 Apr 2001 19:58:54 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: xfs_bmap.c:3130: internal error--unrecognizable insn: Date: Sun, 01 Apr 2001 19:52:57 +0200 Message-ID: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f31HxIM15326 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear All, I am playing with a Slackware-current on an i586 box, I have been able to run Linux 2.4.3-XFS using the latest patches, but I can't turn on debugging because I get this error: xfs_bmap.c: In function `xfs_bmap_del_extent': xfs_bmap.c:3130: internal error--unrecognizable insn: (insn/i 528 527 2172 (parallel[ (set (reg:SI 0 %eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 269)) (set (reg:SI 1 %edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 %edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 269)) ] ) -1 (insn_list 495 (nil)) (nil)) cpp: output pipe has been closed make[3]: *** [xfs_bmap.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_xfs] Error 2 make: *** [_dir_fs] Error 2 From owner-linux-xfs@oss.sgi.com Sun Apr 1 11:38:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Ic8c15993 for linux-xfs-outgoing; Sun, 1 Apr 2001 11:38:08 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31Ic7M15990 for ; Sun, 1 Apr 2001 11:38:07 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31IbxhQ002219; Sun, 1 Apr 2001 13:38:03 -0500 (CDT) Message-ID: <3AC77581.17E5D018@thebarn.com> Date: Sun, 01 Apr 2001 13:37:53 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: daedalus@freemail.it CC: linux-xfs@oss.sgi.com Subject: Re: xfs_bmap.c:3130: internal error--unrecognizable insn: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk daedalus@freemail.it wrote: > Dear All, > > I am playing with a Slackware-current on an i586 box, I have been able > to run Linux 2.4.3-XFS using the latest patches, but I can't turn on > debugging because I get this error: > What version gcc are you using? I'm guessing 2.96? it is known to to able to compile XFS drop back to 2.95.2 or 2.91.66 ( preferred) Not somebody did report gcc 3.0 pre to be working, not verified locally. > > xfs_bmap.c: In function `xfs_bmap_del_extent': > xfs_bmap.c:3130: internal error--unrecognizable insn: > (insn/i 528 527 2172 (parallel[ > (set (reg:SI 0 %eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 269)) > (set (reg:SI 1 %edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 %edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 269)) > ] ) -1 (insn_list 495 (nil)) > (nil)) > cpp: output pipe has been closed > make[3]: *** [xfs_bmap.o] Error 1 > make[2]: *** [first_rule] Error 2 > make[1]: *** [_subdir_xfs] Error 2 > make: *** [_dir_fs] Error 2 -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Apr 1 11:55:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Itxq16224 for linux-xfs-outgoing; Sun, 1 Apr 2001 11:55:59 -0700 Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f31ItwM16221 for ; Sun, 1 Apr 2001 11:55:58 -0700 Received: (qmail 19068 invoked from network); 1 Apr 2001 18:55:57 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 1 Apr 2001 18:55:57 -0000 Received: (from ajay@localhost) by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id OAA25026 for linux-xfs@oss.sgi.com; Sun, 1 Apr 2001 14:55:56 -0400 (EDT) Date: Sun, 1 Apr 2001 14:55:56 -0400 From: Ajay Shekhawat To: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch Message-ID: <20010401145556.U16131@zaurak.cedar.buffalo.edu> References: <3AC6733F.3B62AC5E@thebarn.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VaKJWhUROU/xPxjb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AC6733F.3B62AC5E@thebarn.com>; from cattelan@thebarn.com on Sat, Mar 31, 2001 at 06:15:59PM -0600 Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --VaKJWhUROU/xPxjb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 31, 2001 at 06:15:59PM -0600, Russell Cattelan wrote: > A preliminary XFS patch for 2.4.3 has been placed on > oss.sgi.com/linux-xfs.sgi.com > ftp://linux-xfs.sgi.com/projects/xfs/download/patches/ > > This has passed basic bonnie and dbench runs, but has > not been extensivly tested, but due to the limited number > of changes things should work just fine. > > The CVS tree will be updated in the next few days. > > -Russell I built the 2.4.3-XFS kernel on our test machine, and tried hammering on the machine via NFS. Unfortunately, after about 10 hours or so of work, I get an "oops". The messages are attached below. It _appears_ that the machine is running out of some resource. The second 'oops' below occured when I tried to rlogin into the machine; it is caused by "tcsh" ! Any help in tracking this down would be appreciated. Ajay --VaKJWhUROU/xPxjb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ksymoops.txt.20" ksymoops 2.4.0 on i686 2.4.3-XFS. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-XFS/ (specified) -m /boot/System.map-2.4.3-XFS (specified) Apr 1 07:55:57 mymachine kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000073 Apr 1 07:55:57 mymachine kernel: c01712a0 Apr 1 07:55:57 mymachine kernel: *pde = 00000000 Apr 1 07:55:57 mymachine kernel: Oops: 0000 Apr 1 07:55:57 mymachine kernel: CPU: 1 Apr 1 07:55:57 mymachine kernel: EIP: 0010:[nfsd_cache_lookup+132/676] Apr 1 07:55:57 mymachine kernel: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Apr 1 07:55:57 mymachine kernel: EFLAGS: 00010213 Apr 1 07:55:57 mymachine kernel: eax: 00000021 ebx: 00000063 ecx: 3104cb10 edx: cf0a8f08 Apr 1 07:55:57 mymachine kernel: esi: c031b360 edi: ceff4014 ebp: cf02c200 esp: ceff3f38 Apr 1 07:55:57 mymachine kernel: ds: 0018 es: 0018 ss: 0018 Apr 1 07:55:57 mymachine kernel: Process nfsd (pid: 649, stackpage=ceff3000) Apr 1 07:55:57 mymachine kernel: Stack: cf02c200 c031b360 ceff4014 cf02c200 00000008 00000002 00000011 3104cb10 Apr 1 07:55:57 mymachine kernel: c016a774 cf02c200 00000002 cf02c338 c031b360 ceff8e90 c02992e8 cf02c200 Apr 1 07:55:57 mymachine kernel: ceff4014 ceff2000 003d869e c14706a0 ceff2000 ceff8e00 c031b700 00000000 Apr 1 07:55:57 mymachine kernel: Call Trace: [nfsd_dispatch+60/360] [svc_process+684/1348] [nfsd+427/824] [kernel_thread+35/48] Apr 1 07:55:57 mymachine kernel: Call Trace: [] [] [] [] Apr 1 07:55:57 mymachine kernel: Code: 80 7b 10 00 74 49 8b 4c 24 1c 3b 4b 24 75 40 8b 4c 24 10 3b >>EIP; c01712a0 <===== Trace; c016a774 Trace; c02992e8 Trace; c016a5ab Trace; c0105503 Code; c01712a0 00000000 <_EIP>: Code; c01712a0 <===== 0: 80 7b 10 00 cmpb $0x0,0x10(%ebx) <===== Code; c01712a4 4: 74 49 je 4f <_EIP+0x4f> c01712ef Code; c01712a6 6: 8b 4c 24 1c mov 0x1c(%esp,1),%ecx Code; c01712aa a: 3b 4b 24 cmp 0x24(%ebx),%ecx Code; c01712ad d: 75 40 jne 4f <_EIP+0x4f> c01712ef Code; c01712af f: 8b 4c 24 10 mov 0x10(%esp,1),%ecx Code; c01712b3 13: 3b 00 cmp (%eax),%eax --VaKJWhUROU/xPxjb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ksymoops.txt.33" ksymoops 2.4.0 on i686 2.4.3-XFS. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-XFS/ (specified) -m /boot/System.map-2.4.3-XFS (specified) Apr 1 10:30:36 mymachine kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Apr 1 10:30:36 mymachine kernel: c0144495 Apr 1 10:30:36 mymachine kernel: *pde = 00000000 Apr 1 10:30:36 mymachine kernel: Oops: 0000 Apr 1 10:30:36 mymachine kernel: CPU: 0 Apr 1 10:30:36 mymachine kernel: EIP: 0010:[d_lookup+101/276] Apr 1 10:30:36 mymachine kernel: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Apr 1 10:30:36 mymachine kernel: EFLAGS: 00010207 Apr 1 10:30:36 mymachine kernel: eax: cff99e70 ebx: 000007e8 ecx: 0000000f edx: cff80000 Apr 1 10:30:36 mymachine kernel: esi: 01c4ddc5 edi: cf903e10 ebp: 00000800 esp: cf903db4 Apr 1 10:30:36 mymachine kernel: ds: 0018 es: 0018 ss: 0018 Apr 1 10:30:36 mymachine kernel: Process tcsh (pid: 5655, stackpage=cf903000) Apr 1 10:30:36 mymachine kernel: Stack: 01c4ddc5 00000000 cf903e10 cf903e34 cff99e70 cd85200f 01c4ddc5 00000004 Apr 1 10:30:36 mymachine kernel: c013b364 ceb8bec0 cf903e10 01c4ddc5 c013bc72 ceb8bec0 cf903e10 00000000 Apr 1 10:30:36 mymachine kernel: 00000000 cd852000 cf903e34 080c8888 cf902000 00000009 00000000 cd85200f Apr 1 10:30:36 mymachine kernel: Call Trace: [cached_lookup+16/84] [path_walk+1586/2208] [open_exec+39/184] [reclaim_page+814/1064] [do_execve+30/496] [__alloc_pages+316/752] [do_wp_page+552/608] Apr 1 10:30:36 mymachine kernel: Call Trace: [] [] [] [] [] [] [] Apr 1 10:30:36 mymachine kernel: [] [] [] [] [] [] [] [] Apr 1 10:30:36 mymachine kernel: [] Apr 1 10:30:36 mymachine kernel: Code: 8b 6d 00 8b 74 24 18 39 73 48 0f 85 7e 00 00 00 8b 74 24 24 >>EIP; c0144495 <===== Trace; c013b364 Trace; c013bc72 Trace; c01394e7 Trace; c0129586 Trace; c0139f46 Trace; c012b004 <__alloc_pages+13c/2f0> Trace; c011fe8c Trace; c011fe9e Trace; c0120577 Trace; c010fb09 Trace; c010f9b0 Trace; c011da44 Trace; c01f9e0b Trace; c013b0db Trace; c0105923 Trace; c0106feb Code; c0144495 00000000 <_EIP>: Code; c0144495 <===== 0: 8b 6d 00 mov 0x0(%ebp),%ebp <===== Code; c0144498 3: 8b 74 24 18 mov 0x18(%esp,1),%esi Code; c014449c 7: 39 73 48 cmp %esi,0x48(%ebx) Code; c014449f a: 0f 85 7e 00 00 00 jne 8e <_EIP+0x8e> c0144523 Code; c01444a5 10: 8b 74 24 24 mov 0x24(%esp,1),%esi --VaKJWhUROU/xPxjb-- From owner-linux-xfs@oss.sgi.com Sun Apr 1 11:57:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Ivhj16250 for linux-xfs-outgoing; Sun, 1 Apr 2001 11:57:43 -0700 Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f31IvgM16247 for ; Sun, 1 Apr 2001 11:57:42 -0700 Received: (qmail 19073 invoked from network); 1 Apr 2001 18:57:42 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 1 Apr 2001 18:57:42 -0000 Received: (from ajay@localhost) by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id OAA25032; Sun, 1 Apr 2001 14:57:41 -0400 (EDT) Date: Sun, 1 Apr 2001 14:57:41 -0400 From: Ajay Shekhawat To: Robin Humble Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch Message-ID: <20010401145741.V16131@zaurak.cedar.buffalo.edu> References: <3AC6733F.3B62AC5E@thebarn.com> <200104010624.GAA28512@groucho.maths.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104010624.GAA28512@groucho.maths.monash.edu.au>; from rjh@groucho.maths.monash.edu.au on Sun, Apr 01, 2001 at 04:24:25PM +1000 Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 01, 2001 at 04:24:25PM +1000, Robin Humble wrote: > Secondary: > Working 3c905b is the next most important thing... is this broken in > 2.4.2 (as reported on this list) and fixed in 2.4.3 do you think? > We're getting problems with dual 3c905b's... I thought it was IRQ > issues, but we tried workarounds for that - maybe it's the 2.4.2 kernel? > > cheers, > robin >From my limited amount of testing, the 3c59x module seems to be more stable. Earlier, I would get errors from the module when the machine was stressed; now this is not the case. Ajay From owner-linux-xfs@oss.sgi.com Sun Apr 1 14:05:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31L5XQ18437 for linux-xfs-outgoing; Sun, 1 Apr 2001 14:05:33 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31L5WM18434 for ; Sun, 1 Apr 2001 14:05:32 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f31L5RbA001337; Sun, 1 Apr 2001 16:05:29 -0500 (CDT) Message-ID: <3AC79810.ED6F7061@thebarn.com> Date: Sun, 01 Apr 2001 16:05:21 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Shekhawat CC: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch References: <3AC6733F.3B62AC5E@thebarn.com> <20010401145556.U16131@zaurak.cedar.buffalo.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ajay Shekhawat wrote: > On Sat, Mar 31, 2001 at 06:15:59PM -0600, Russell Cattelan wrote: > > A preliminary XFS patch for 2.4.3 has been placed on > > oss.sgi.com/linux-xfs.sgi.com > > ftp://linux-xfs.sgi.com/projects/xfs/download/patches/ > > > > This has passed basic bonnie and dbench runs, but has > > not been extensivly tested, but due to the limited number > > of changes things should work just fine. > > > > The CVS tree will be updated in the next few days. > > > > -Russell > > I built the 2.4.3-XFS kernel on our test machine, and tried hammering on > the machine via NFS. Unfortunately, after about 10 hours or so of work, > I get an "oops". The messages are attached below. It _appears_ that the > machine is running out of some resource. The second 'oops' below occured > when I tried to rlogin into the machine; it is caused by "tcsh" ! > Off hand I really don't have any suggestions . Best guess looking at this would be either a bad dcache entry or like you said some resource is being exhausted. I suppose looking at some stats in /proc might help. all though without knowing what resource it running low, what to watch? could you turn on kdb? so we can start looking at the problem with that? > > Any help in tracking this down would be appreciated. > > Ajay > > ------------------------------------------------------------------------ > > ksymoops.txt.20Name: ksymoops.txt.20 > Type: Plain Text (text/plain) > > ksymoops.txt.33Name: ksymoops.txt.33 > Type: Plain Text (text/plain) -- Russell Cattelan cattelan@thebarn.com From owner-linux-xfs@oss.sgi.com Sun Apr 1 16:11:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31NBLq20189 for linux-xfs-outgoing; Sun, 1 Apr 2001 16:11:21 -0700 Received: from fencepost.gnu.org (we-refuse-to-spy-on-our-users@fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31NBKM20186 for ; Sun, 1 Apr 2001 16:11:20 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 3.16 #1 (Debian)) id 14jqzr-0003y1-00; Sun, 01 Apr 2001 19:10:59 -0400 Date: Sun, 1 Apr 2001 19:10:59 -0400 From: Lennert Buytenhek To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: 2.4.2-XFS stability? (was: Re: O_DIRECT buglet) Message-ID: <20010401191059.A6160@gnu.org> References: <20010401121248.A14579@gnu.org> <3AC75B93.19AB5A8C@thebarn.com> <20010401125601.A15276@gnu.org> <3AC75E89.7AFE485A@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AC75E89.7AFE485A@thebarn.com>; from cattelan@thebarn.com on Sun, Apr 01, 2001 at 11:59:53AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (please CC on replies) On Sun, Apr 01, 2001 at 11:59:53AM -0500, Russell Cattelan wrote: > > > page aligned memory is necessary > > > > Doh. I know how O_DIRECT works, thank you. Please reread my original mail. > > Arggh terribly sorry... guess I didn't have enough coffee yet this morning. Sorry for being rude there. Thanks for looking into it. Another thing: how stable is 2.4.2-XFS supposed to be? I'm getting dcache- related oopses about twice a day on four machines under moderate load (typically three rsync's, xfs_fsr), but I have no idea whether this is XFS-related or not. cheers, Lennert -- first oops Mar 30 23:49:56 mara kernel: Unable to handle kernel paging request at virtual address 00080000 Mar 30 23:49:56 mara kernel: printing eip: Mar 30 23:49:56 mara kernel: c013a7d4 Mar 30 23:49:56 mara kernel: *pde = 00000000 Mar 30 23:49:56 mara kernel: Oops: 0000 Mar 30 23:49:56 mara kernel: CPU: 0 Mar 30 23:49:56 mara kernel: EIP: 0010:[cached_lookup+32/84] Mar 30 23:49:56 mara kernel: EFLAGS: 00010206 Mar 30 23:49:56 mara kernel: eax: 00080000 ebx: c63dd1a0 ecx: c63dd240 edx: c6c914c0 Mar 30 23:49:56 mara kernel: esi: 00000000 edi: c1c59f68 ebp: c6762019 esp: c1c59f30 Mar 30 23:49:56 mara kernel: ds: 0018 es: 0018 ss: 0018 Mar 30 23:49:56 mara kernel: Process du (pid: 4013, stackpage=c1c59000) Mar 30 23:49:56 mara kernel: Stack: 9c5b346b c013af9b c649c4c0 c1c59f68 00000000 c6762000 00000000 c1c59fa4 Mar 30 23:49:56 mara kernel: bffff380 c1c58000 c013a5db c1c58000 00000008 00000000 c6762000 00000019 Mar 30 23:49:56 mara kernel: 9c5b346b c013b5d8 c6762000 c1c59fa4 c1c58000 c1c59fa4 00000000 c0138626 Mar 30 23:49:56 mara kernel: Call Trace: [path_walk+1431/2076] [getname+91/160] [__user_walk+60/88] [sys_lstat64+22/112] [sys_close+67/84] [system_call+51/56] Mar 30 23:49:56 mara kernel: Mar 30 23:49:56 mara kernel: Code: 8b 10 85 d2 74 27 8b 44 24 10 50 53 ff d2 83 c4 08 85 c0 75 -- cached_lookup c013a7b4 : c013a7b4: 53 push %ebx c013a7b5: 8b 54 24 08 mov 0x8(%esp,1),%edx c013a7b9: 8b 44 24 0c mov 0xc(%esp,1),%eax c013a7bd: 50 push %eax c013a7be: 52 push %edx c013a7bf: e8 c4 80 00 00 call c0142888 c013a7c4: 89 c3 mov %eax,%ebx c013a7c6: 83 c4 08 add $0x8,%esp c013a7c9: 85 db test %ebx,%ebx c013a7cb: 74 34 je c013a801 c013a7cd: 8b 43 50 mov 0x50(%ebx),%eax c013a7d0: 85 c0 test %eax,%eax c013a7d2: 74 2d je c013a801 c013a7d4: 8b 10 mov (%eax),%edx c013a7d6: 85 d2 test %edx,%edx c013a7d8: 74 27 je c013a801 c013a7da: 8b 44 24 10 mov 0x10(%esp,1),%eax c013a7de: 50 push %eax c013a7df: 53 push %ebx c013a7e0: ff d2 call *%edx c013a7e2: 83 c4 08 add $0x8,%esp -- second (similar) oops Mar 31 00:17:35 mara kernel: Unable to handle kernel paging request at virtual address 00080000 Mar 31 00:17:35 mara kernel: printing eip: Mar 31 00:17:35 mara kernel: c013a7d4 Mar 31 00:17:35 mara kernel: *pde = 00000000 Mar 31 00:17:35 mara kernel: Oops: 0000 Mar 31 00:17:35 mara kernel: CPU: 0 Mar 31 00:17:35 mara kernel: EIP: 0010:[cached_lookup+32/84] Mar 31 00:17:35 mara kernel: EFLAGS: 00010206 Mar 31 00:17:35 mara kernel: eax: 00080000 ebx: c63dd1a0 ecx: 00000000 edx: c7fc0000 Mar 31 00:17:35 mara kernel: esi: 00000000 edi: c25fff68 ebp: c1df8019 esp: c25fff30 Mar 31 00:17:35 mara kernel: ds: 0018 es: 0018 ss: 0018 Mar 31 00:17:35 mara kernel: Process du (pid: 4344, stackpage=c25ff000) Mar 31 00:17:35 mara kernel: Stack: 9c5b346b c013af9b c649c4c0 c25fff68 00000000 c1df8000 00000000 c25fffa4 Mar 31 00:17:35 mara kernel: bffff250 c25fe000 c013a5db c25fe000 00000008 00000000 c1df8000 00000019 Mar 31 00:17:35 mara kernel: 9c5b346b c013b5d8 c1df8000 c25fffa4 c25fe000 c25fffa4 00000000 c0138626 Mar 31 00:17:35 mara kernel: Call Trace: [path_walk+1431/2076] [getname+91/160] [__user_walk+60/88] [sys_lstat64+22/112] [sys_close+67/84] [system_call+51/56] Mar 31 00:17:35 mara kernel: Mar 31 00:17:35 mara kernel: Code: 8b 10 85 d2 74 27 8b 44 24 10 50 53 ff d2 83 c4 08 85 c0 75 -- third oops Apr 2 00:39:53 mara kernel: Unable to handle kernel paging request at virtual address 00080014 Apr 2 00:39:53 mara kernel: printing eip: Apr 2 00:39:53 mara kernel: c01423be Apr 2 00:39:53 mara kernel: *pde = 00000000 Apr 2 00:39:53 mara kernel: Oops: 0000 Apr 2 00:39:53 mara kernel: CPU: 0 Apr 2 00:39:53 mara kernel: EIP: 0010:[prune_dcache+194/332] Apr 2 00:39:53 mara kernel: EFLAGS: 00010206 Apr 2 00:39:53 mara kernel: eax: 00080000 ebx: c63dd1c0 ecx: c63cb090 edx: c63cb090 Apr 2 00:39:53 mara kernel: esi: c63dd1a0 edi: c63cb080 ebp: 00000184 esp: c7f97fa4 Apr 2 00:39:53 mara kernel: ds: 0018 es: 0018 ss: 0018 (This is all I have of this oops.) -- prune_dcache c01423a6: 8b 56 38 mov 0x38(%esi),%edx c01423a9: 8b 48 04 mov 0x4(%eax),%ecx c01423ac: 89 4a 04 mov %ecx,0x4(%edx) c01423af: 89 11 mov %edx,(%ecx) c01423b1: 89 46 38 mov %eax,0x38(%esi) c01423b4: 89 40 04 mov %eax,0x4(%eax) c01423b7: 8b 46 50 mov 0x50(%esi),%eax c01423ba: 85 c0 test %eax,%eax c01423bc: 74 12 je c01423d0 c01423be: 8b 40 14 mov 0x14(%eax),%eax c01423c1: 85 c0 test %eax,%eax c01423c3: 74 0b je c01423d0 c01423c5: 57 push %edi c01423c6: 56 push %esi c01423c7: ff d0 call *%eax c01423c9: 83 c4 08 add $0x8,%esp c01423cc: eb 12 jmp c01423e0 c01423ce: 89 f6 mov %esi,%esi c01423d0: 57 push %edi c01423d1: e8 8a 1b 00 00 call c0143f60 c01423d6: 83 c4 04 add $0x4,%esp c01423d9: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi c01423e0: 8b 5e 0c mov 0xc(%esi),%ebx c01423e3: 8b 46 50 mov 0x50(%esi),%eax From owner-linux-xfs@oss.sgi.com Mon Apr 2 05:06:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32C6vV09834 for linux-xfs-outgoing; Mon, 2 Apr 2001 05:06:57 -0700 Received: from ns.tecosim.de (ns.tecosim.de [194.24.222.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32C6rM09828 for ; Mon, 2 Apr 2001 05:06:53 -0700 Received: from donner.tecosim.de (root@donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA26250; Mon, 2 Apr 2001 14:06:49 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f32C6mZ01300; Mon, 2 Apr 2001 14:06:48 +0200 Date: Mon, 2 Apr 2001 14:06:48 +0200 From: Utz Lehmann To: Russell Cattelan Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs Message-ID: <20010402140648.A1150@tecosim.de> References: <20010329165519.A7386@tecosim.de> <20010329170446.B7386@tecosim.de> <3AC35E8D.711963C5@sgi.com> <20010329181419.G7386@tecosim.de> <20010329182044.H7386@tecosim.de> <3AC38727.FC9C4FC8@thebarn.com> <20010330115628.A1146@tecosim.de> <3AC4A50F.B141110B@thebarn.com> <20010330192006.A1149@tecosim.de> <3AC51AE5.5E396D14@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AC51AE5.5E396D14@thebarn.com>; from cattelan@thebarn.com on Fri, Mar 30, 2001 at 06:46:45PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi For your information: I just test a 2.4.3 kernel + prerelease 0.10 patch. It hangs also during shutdown umount. utz From owner-linux-xfs@oss.sgi.com Mon Apr 2 06:16:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32DGj212764 for linux-xfs-outgoing; Mon, 2 Apr 2001 06:16:45 -0700 Received: from ns.tecosim.de (ns.tecosim.de [194.24.222.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32DGeM12761 for ; Mon, 2 Apr 2001 06:16:40 -0700 Received: from donner.tecosim.de (root@donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA28105; Mon, 2 Apr 2001 15:16:37 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f32DGbs03295; Mon, 2 Apr 2001 15:16:37 +0200 Date: Mon, 2 Apr 2001 15:16:37 +0200 From: Utz Lehmann To: Russell Cattelan Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs Message-ID: <20010402151637.C1537@tecosim.de> References: <20010329170446.B7386@tecosim.de> <3AC35E8D.711963C5@sgi.com> <20010329181419.G7386@tecosim.de> <20010329182044.H7386@tecosim.de> <3AC38727.FC9C4FC8@thebarn.com> <20010330115628.A1146@tecosim.de> <3AC4A50F.B141110B@thebarn.com> <20010330192006.A1149@tecosim.de> <3AC51AE5.5E396D14@thebarn.com> <20010402110010.A1147@tecosim.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010402110010.A1147@tecosim.de>; from leh@tecosim.de on Mon, Apr 02, 2001 at 11:00:10AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Resend, because my original mail seems to be lost. Utz Lehmann [leh@tecosim.de] wrote: > Hi > > There was no pagebuf_iostart function in the back trace, i used > pagebuf_iorequest, hope thats right. > > utz > > > Entering kdb (current=0xc035a000, pid 0) due to Keyboard Entry > kdb> ps > Task Addr Pid Parent [*] cpu State Thread Command > 0xc15fe000 00000001 00000000 0 000 stop 0xc15fe260 init > 0xc15f0000 00000002 00000001 0 000 stop 0xc15f0260 keventd > 0xc15ec000 00000003 00000001 0 000 stop 0xc15ec260 kswapd > 0xc15ea000 00000004 00000001 0 000 stop 0xc15ea260 kreclaimd > 0xc15e8000 00000005 00000001 0 000 stop 0xc15e8260 bdflush > 0xc15e6000 00000006 00000001 0 000 stop 0xc15e6260 kupdate > 0xc1580000 00000007 00000001 0 000 stop 0xc1580260 mdrecoveryd > 0xc1562000 00000008 00000001 0 000 stop 0xc1562260 pagebuf_daemon > 0xce516000 00001716 00000001 0 000 stop 0xce516260 rc > 0xce2b4000 00002102 00001716 0 000 stop 0xce2b4260 S20reboot > 0xcf818000 00002123 00002102 0 000 stop 0xcf818260 umount > kdb> btp 2123 > EBP EIP Function(args) > 0xcf819e58 0xc0112b18 schedule+0x2d8 > kernel .text 0xc0100000 0xc0112840 0xc0112c70 > 0xc015fb13 pagebuf_iorequest+0x103 (0xce3e5d80) > kernel .text 0xc0100000 0xc015fa10 0xc015fba0 > 0xc01c7c47 xfs_bdstrat_cb+0x27 (0xce3e5d80) > kernel .text 0xc0100000 0xc01c7c20 0xc01c7c70 > 0xc0160763 pagebuf_delwri_flush+0xd3 (0xcf7e3ac0, 0x1, 0xcf819ec8) > kernel .text 0xc0100000 0xc0160690 0xc0160880 > 0xc01c7d2d XFS_bflush+0x1d (0xcf7e3ac0, 0x3a01) > kernel .text 0xc0100000 0xc01c7d10 0xc01c7d40 > 0xc01b6873 xfs_unmount+0xd3 (0xcf7d9400, 0x0, 0xc03b16a0) > kernel .text 0xc0100000 0xc01b67a0 0xc01b6920 > 0xc01c189a fs_dounmount+0x5a (0xcf7d9400, 0x0, 0x0, 0xc03b16a0, 0xcf7e3dc4) > kernel .text 0xc0100000 0xc01c1840 0xc01c18c0 > 0xc01c8d38 linvfs_put_super+0x58 (0xcf8b6800) > kernel .text 0xc0100000 0xc01c8ce0 0xc01c8db0 > 0xc0136867 kill_super+0x87 (0xcf8b6800, 0x0, 0xc156cf40, 0xffffffff, 0xcfb73ac0) > kernel .text 0xc0100000 0xc01367e0 0xc0136920 > 0xc0136c71 do_umount+0x1c1 (0xc156cf40, 0x0, 0x0) > kernel .text 0xc0100000 0xc0136ab0 0xc0136c80 > 0xc0136d46 sys_umount+0xc6 (0x8052430, 0x0) > more> > kernel .text 0xc0100000 0xc0136c80 0xc0136d80 > 0xc0136d8c sys_oldumount+0xc (0x8052430, 0x804ee27, 0x8052478, 0x8052431, 0x804ee20) > kernel .text 0xc0100000 0xc0136d80 0xc0136d90 > 0xc0108f77 system_call+0x33 > kernel .text 0xc0100000 0xc0108f44 0xc0108f7c > kdb> pb 0xce3e5d80 > page_buf_t at 0xce3e5d80 > pb_flags WRITE MAPPED MAPPABLE LOCK LOCKABLE ALL_PAGES_MAPPED MEM_ALLOCATED > pb_target 0xcf7e3ac0 pb_hold 1 pb_next 0xcf7d49c0 pb_prev 0xc144a848 > pb_file_offset 0x18000200 pb_buffer_length 0x200 pb_addr 0xcf600200 > pb_bn 0xc0001 pb_count_desired 0x200 > pb_io_remaining 0 pb_error 0 pb_mem 0xcf5fe180 > pb_iodonesema (0,0) pb_sema (0,0) pincount (1) > pb_fspriv 0xcff2f648 pb_fspriv2 0x00000000 > kdb> reboot > > > > Russell Cattelan [cattelan@thebarn.com] wrote: > > Utz Lehmann wrote: > > > > Well drat... seems to be a really problem here. > > > > Not sure we are going to be able to debug this remotely, hopefully we will be able > > to reproduce the problem here. > > But if you could extract a bit more info.... > > > > load the modules kdbm_pg and xfsidbg. > > once the system is hung break into kdb backtrace > > the unmount command, then grab the first address in > > the pagebuf_iostart function and feed it to kdb > > kdb> pb
> > > > We are looking for the pincount and the lock status. > > It would seem somehow the pg_delwri_flush is waiting for > > the pagebuf to get unpinned, which should have already happened > > before this point. > > My guess is that somehow a pagebuf is getting re-inserted into the delwri queue > > while the flush code in trying to work on pushing everything out. From owner-linux-xfs@oss.sgi.com Mon Apr 2 06:39:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Ddda13309 for linux-xfs-outgoing; Mon, 2 Apr 2001 06:39:39 -0700 Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32DdbM13306 for ; Mon, 2 Apr 2001 06:39:38 -0700 Received: from ip090.pool-06.cyb.it (ip090.pool-06.cyb.it [195.191.4.219]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f32DdRV24054 for ; Mon, 2 Apr 2001 15:39:31 +0200 From: daedalus@freemail.it To: linux-xfs@oss.sgi.com Subject: Re: xfs_bmap.c:3130: internal error--unrecognizable insn: Date: Mon, 02 Apr 2001 15:33:03 +0200 Message-ID: References: <3AC77581.17E5D018@thebarn.com> In-Reply-To: <3AC77581.17E5D018@thebarn.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f32DddM13307 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 01 Apr 2001 13:37:53 -0500, Russell Cattelan wrote: >What version gcc are you using? I'm guessing 2.96? gcc-2.95.2 and binutils-2.10.1.0.4 From owner-linux-xfs@oss.sgi.com Mon Apr 2 07:23:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32ENIa15317 for linux-xfs-outgoing; Mon, 2 Apr 2001 07:23:18 -0700 Received: from esparrall.udg.es (esparrall.udg.es [130.206.124.16]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32EN0M15308 for ; Mon, 2 Apr 2001 07:23:00 -0700 Received: from gcs by esparrall.udg.es with local (Exim 3.22 #1 (Debian)) id 14k57n-0002jv-00 for ; Mon, 02 Apr 2001 16:16:07 +0200 Date: Mon, 2 Apr 2001 16:16:07 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: Strange error with kernel 2.4.3 Message-ID: <20010402161607.A10485@esparrall.udg.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, I have installed the new kernel, with XFS ofcourse :-). Well, tried a test with bonnie++ with a 7Gb test file (7x1Gb actually, as it is automatically splitted). I started it for the night, and next morning I saw this on the console: Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page Bad swap file entry 00000020 swap_free: Trying to free nonexistent swap-page swap_free: Trying to free nonexistent swap-page Is it the kernel itself, or the XFS implementation (maybe other)? What's this by the way? Thanks, GCS From owner-linux-xfs@oss.sgi.com Mon Apr 2 08:41:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Ff9s17292 for linux-xfs-outgoing; Mon, 2 Apr 2001 08:41:09 -0700 Received: from galactica.it (mail2.galactica.it [212.41.208.19] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32Ff8M17289 for ; Mon, 2 Apr 2001 08:41:08 -0700 Received: from birrella.alcol.it ([62.122.10.85]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 2 Apr 2001 17:37:52 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Michele Baldessari To: linux-xfs@oss.sgi.com Subject: Just joined..couple of questions Date: Mon, 2 Apr 2001 17:38:46 +0200 X-Mailer: KMail [version 1.2.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <09a495237150241MAIL2@galactica.it> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just joined this list, I'm still checking out the CVS tree and I had two questions about testing : Are you more interested in tests from a specific branch (in this case, which one?)? Definitely keep things simple by using egcs or is there interest in testing against gcc-2.96 (I always use the latest one from rawhide, gcc-2.96-79 at the moment)? I know this one is mentioned on the faq. (Just wanted to know if there is any interest) Ciao, Michele -- Computers are like airconditioners: They stop working properly if you open windows. From owner-linux-xfs@oss.sgi.com Mon Apr 2 09:38:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Gc0718604 for linux-xfs-outgoing; Mon, 2 Apr 2001 09:38:00 -0700 Received: from thor.theseus.com (south.orl-pub.theseus.com [12.108.42.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32GbwM18601 for ; Mon, 2 Apr 2001 09:37:59 -0700 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id MAA30917; Mon, 2 Apr 2001 12:43:17 -0400 Message-ID: <3AC8AB43.C6DC30CC@theseus.com> Date: Mon, 02 Apr 2001 12:39:31 -0400 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, nfs@lists.sourceforge.net Subject: [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -------- Original Message -------- From: Bryan-TheBS-Smith Subject: [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission Date: 2001 April 02 [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission USING A PASSPORT.COM-ENABLED SERVICE WILL DUAL-COPYRIGHT/LICENSE YOUR ORIGINAL WORK I just want to throw this out for *OFF-LIST* discussion. I am currently writing an article on the new licensing agreement at Microsoft's Passport.COM. What most people don't realize is that if you use MSN, Hotmail, Expedia and, in some cases, just MS IE/Outlook, you have _already_agreed_ to this license. Why? In the case of MSN, Hotmail and Expedia, your passwords are stored on Passport.COM (remember when Microsoft went down in late 1999 because of their expiration of Passport.COM?). I am still researching the depth of Passport.COM's interaction with MS IE itself (seperate from these services), and other Microsoft and non-Microsoft, Internet-enabled software. The problem? In a nutshell, any outgoing information, software and/or services of your original copyright/license/IP are "dual copyrighted/licensed" to Microsoft c/o this new agreement. This can be _very_dangerous_ from the standpoint of free software development. Worse yet is the fact that no one currently knows to what extent the Passport.COM licensing agreement applies, but it seems all MSN, Hotmail and Expedia users are subject to it, possibly all users of MS IE as well. GPL DOES NOT OVERRIDE YOUR COPYRIGHTS (NOR YOUR ABILITY TO ASSIGN THEM TO OTHERS) Now you may think the GPL (and/or other GNU licensed works like the LGPL, FDL, etc...) protects your work. What you may not realize is that Copyright Law is the _ultimate_ law. The software that cracked the encryption (really "uglification") and revealed the follies of popular "Internet Filtering" software were perfect examples. The software was released GPL, but then revoked later. How? Because the creators ultimately have "all rights reserved" to their copyright, and can revoke any license at any time (like they did when the popular filtering software vendors bought the rights). When you post, upload or otherwise transmit through a Passport.COM-enabled service, you are effectively giving Microsoft a non-exclusive, "blank 'copyright' check" to use your work. Now one way you can "protect" your free software/works from being submissive to this "hole" in Copyright Law is to assign all rights to the Free Software Foundation. In fact, this is exactly what the FSF recommends you do with any GNU licensed work. If you have not done so already, consider doing this with any GPL, LGPL, FDL or other GNU-licensed work that you do not plan to "dual-license" yourself or other entity. IS THIS AN "ANAL" STANCE? MICROSOFT "REALITY CHECK": Now before you think I'm going off an being "anal" on this, or screaming "the sky is falling," realize the following: 1. Many companies are looking for new avenues of revenue and the "total forfeit" or "dual-copyright/licensure" of your copyright/licenses/IP is nothing new. 2. Microsoft (among others, even non-Windows vendors) have been shown time and time again to be all for #1, and abusing the rights of others in the name of profits. 3. *BIG ONE*: Anyone who has interviewed with Microsoft, or visited the Microsoft campus knows that Microsoft's future goals _include_ the revenue stream of _charging_you_ to even see your own data! 4. *ANOTHER*: Microsoft has identified "dual-copyright/licensure" as a key method to "bypassing" the "GPL virus." 5. *MOST IMPORTANTLY*: Microsoft is currently the biggest lobbyist of the US government, and expends the most in legal costs of any American company. Lawyers are difference between something just being just "unethical and not legally binding" and "unethical but quite legal binding and quite enforcable." #5 is what makes the Passport.COM licensing agreement the most scary, even though it is nothing new in some circles. WHAT SHOULD THE FREE SOFTWARE COMMUNITY DO TO COMBAT THIS? Other than avoiding these services and any other that use Passport.COM (which will only get harder and harder as .NET makes it presence), there are some _real_issues_ to doing _anything_ on the Internet that will require our action. At least two key issues need to be addressed (with possible solutions): 1. "Identify" users who are using these services when they contact your web site, archive, CVS repository, etc... They need not only be informed of these issues -- but they need to "sign" a "counter agreement" that they agree to the policies of our site, archive, repository, etc... which either "prohibit" uploading from services where there is such an agreement and/or somehow put the responsibility on the consumer and/or service to NOT allow such "dual-copyright/licensure" rights to be applicable to those original works. "Identification" is where the difficulty may come in, but searching for a cookie or other known "resource" on the client system should provide us with a good indicator that the client is using these services. Our service then will "redirect" them to the proper page with the agreement (and kick them off if they do not). 2. Draft new licenses, or create "addendeum" to existing licenses that explicitly target these other agreements and render them either null and void, or somehow limit their application to our projects. This will be most difficult as the creators of these "agreements" have been smart enough to make their copyright/licensure "non-exclusive" -- which allows the creation of a "dual-copyrighted/licensed" version they can use (whereas an "exclusive" agreement would not hold up in court). Again, these are serious issues that need to be addressed ASAP. I hope the free software community pulls together and does its due dillengence to combatting this serious violation of our IP and our ability to control who, what and how it is copyrighted and/or licensed. LINKS TO MORE INFORMATION: As a follow-up, please take the time to read the following URLs: Microsoft Passport.COM terms of use: http://www.passport.com/Consumer/TermsOfUse.asp The Register.COM article: http://www.theregister.co.uk/content/4/18002.html Troubleshooters.COM new copyright and other articles: http://www.troubleshooters.com/cpyright.htm http://www.troubleshooters.com/tpromag/200104/200104.htm#_new_copyright http://www.troubleshooters.com/tpromag/200104/200104.htm#_three_articles LEAP Thread (first article in thread): http://lists.leap-cf.org/pipermail/leaplist/2001-April/011248.html -- Bryan "TheBS" Smith OSS/GNU/Linux Participant, Advocate, Packager and Developer P.S. Feel free to forward this to others, provided you are courteous enough to not cross-post a single message among several lists (i.e. please send one message per list or two). -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Mon Apr 2 10:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32H2qx19237 for linux-xfs-outgoing; Mon, 2 Apr 2001 10:02:52 -0700 Received: from astro.umn.edu (hal.astro.umn.edu [128.101.221.100]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32H2pM19234 for ; Mon, 2 Apr 2001 10:02:52 -0700 Received: (qmail 17119 invoked by uid 835); 2 Apr 2001 17:02:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2001 17:02:46 -0000 Date: Mon, 2 Apr 2001 12:02:45 -0500 (CDT) From: kelley eicher To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: How to make an XFS compatible boot floppy? In-Reply-To: <3AC53092.B75961FE@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I haven't yet looked at Kelley's images, but thanks! Maybe you can > tackle making the Linuxcare rescue CD xfs capable! ;) > -Eric ok. i'll try to accomplish this in the next day or so... |< >> kelley j eicher << Sys Admin >> Univ. of MN Astronomy Dept. << ph: (612) 626-2067 or (612) 624-3589 >> fx: (612) 626-2029 << office: 385 physics >> carde@astro.umn.edu From owner-linux-xfs@oss.sgi.com Mon Apr 2 11:16:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32IGs521992 for linux-xfs-outgoing; Mon, 2 Apr 2001 11:16:54 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32IGsM21989 for ; Mon, 2 Apr 2001 11:16:54 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA05088 for ; Mon, 2 Apr 2001 11:27:06 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1333110 for ; Mon, 2 Apr 2001 13:15:37 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA67770 for ; Mon, 2 Apr 2001 13:15:37 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32IDlc21968; Mon, 2 Apr 2001 13:13:47 -0500 Message-Id: <200104021813.f32IDlc21968@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 13:13:47 -0500 Subject: TAKE - more efficient bit searching function Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From kernel profiling this function was a dog, using a more efficient implementation (with permission) from Reiserfs. Date: Mon Apr 2 11:14:34 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91391a linux/fs/xfs/xfs_buf_item.c - 1.112 - Move to a more efficient function to find a bit set in a stream of bytes. Code taken from the reiserfs base (I did ask Chris Mason). From owner-linux-xfs@oss.sgi.com Mon Apr 2 11:20:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32IKkY22323 for linux-xfs-outgoing; Mon, 2 Apr 2001 11:20:46 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32IKkM22319 for ; Mon, 2 Apr 2001 11:20:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06709 for ; Mon, 2 Apr 2001 11:30:58 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA84288; Mon, 2 Apr 2001 13:19:29 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA60590; Mon, 2 Apr 2001 13:19:28 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f32IHcI25141; Mon, 2 Apr 2001 13:17:38 -0500 Message-Id: <200104021817.f32IHcI25141@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Lennert Buytenhek cc: linux-xfs@oss.sgi.com Subject: Re: O_DIRECT buglet In-Reply-To: Message from Lennert Buytenhek of "Sun, 01 Apr 2001 12:12:48 EDT." <20010401121248.A14579@gnu.org> Date: Mon, 02 Apr 2001 13:17:38 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > (Not on the list, please CC on replies) > > Hi, > > Doing O_DIRECT I/O to a buffer which is not on an appropriate block boundary > seem to fail with return code 22 instead of -22 (EINVAL). This is on 2.4.2 > with an XFS tree checkout from 20010329. > > > tia, > Lennert > Yep, this code has negated error code returns in it. Irix keeps errno values positive in the kernel and only at the system call level do they get flipped, the linux convention of when they get set negative is different. We are doing a check to look for other occurences of this and a fix with all the cases we find should be along fairly soon. Steve From owner-linux-xfs@oss.sgi.com Mon Apr 2 11:29:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32ITGF22584 for linux-xfs-outgoing; Mon, 2 Apr 2001 11:29:16 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32ITEM22581 for ; Mon, 2 Apr 2001 11:29:15 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA6731837 for ; Mon, 2 Apr 2001 20:29:12 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1344044 for ; Mon, 2 Apr 2001 13:27:56 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA90392 for ; Mon, 2 Apr 2001 13:27:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32IQ4328693; Mon, 2 Apr 2001 13:26:04 -0500 Message-Id: <200104021826.f32IQ4328693@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 13:26:04 -0500 Subject: TAKE - these files are created during build, remove Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove two files which are created by the build from the checked in code. Date: Mon Apr 2 11:27:18 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91392a linux/drivers/scsi/aic7xxx/aic7xxx_seq.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h - 1.2 - remove - this is a generated file From owner-linux-xfs@oss.sgi.com Mon Apr 2 11:50:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32IoiV23231 for linux-xfs-outgoing; Mon, 2 Apr 2001 11:50:44 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32IohM23228 for ; Mon, 2 Apr 2001 11:50:43 -0700 Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08071 for ; Mon, 2 Apr 2001 11:50:42 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1324649 for ; Mon, 2 Apr 2001 13:49:26 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA58223 for ; Mon, 2 Apr 2001 13:49:26 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32IlZq30465; Mon, 2 Apr 2001 13:47:35 -0500 Message-Id: <200104021847.f32IlZq30465@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 13:47:35 -0500 Subject: TAKE - minor cleanup, unneeded zeroing of data Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 11:49:01 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91395a linux/fs/pagebuf/avl.c - 1.3 - Remove bzero call, we fill in all the fields after here anyway From owner-linux-xfs@oss.sgi.com Mon Apr 2 12:28:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32JSW704163 for linux-xfs-outgoing; Mon, 2 Apr 2001 12:28:32 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32JSWM04160 for ; Mon, 2 Apr 2001 12:28:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA19571 for ; Mon, 2 Apr 2001 12:27:17 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1343592 for ; Mon, 2 Apr 2001 14:27:16 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA40441 for ; Mon, 2 Apr 2001 14:27:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32JPOJ06829; Mon, 2 Apr 2001 14:25:24 -0500 Message-Id: <200104021925.f32JPOJ06829@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 14:25:24 -0500 Subject: TAKE - diff cleanup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 12:26:59 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91397a linux/fs/namei.c - 1.26 - Remove unneeded parts of diff in this file From owner-linux-xfs@oss.sgi.com Mon Apr 2 12:41:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Jfod04399 for linux-xfs-outgoing; Mon, 2 Apr 2001 12:41:50 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32JfoM04396 for ; Mon, 2 Apr 2001 12:41:50 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08309 for ; Mon, 2 Apr 2001 12:52:01 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1343337; Mon, 2 Apr 2001 14:40:32 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA77173; Mon, 2 Apr 2001 14:40:32 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f32JceJ06884; Mon, 2 Apr 2001 14:38:40 -0500 Message-Id: <200104021938.f32JceJ06884@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Michele Baldessari cc: linux-xfs@oss.sgi.com Subject: Re: Just joined..couple of questions In-Reply-To: Message from Michele Baldessari of "Mon, 02 Apr 2001 17:38:46 +0200." <09a495237150241MAIL2@galactica.it> Date: Mon, 02 Apr 2001 14:38:40 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hi, > > I just joined this list, I'm still checking out the CVS tree and I had two > questions about testing : > Are you more interested in tests from a specific branch (in this case, which > one?)? > Definitely keep things simple by using egcs or is there interest in testing > against gcc-2.96 (I always use the latest one from rawhide, gcc-2.96-79 at > the moment)? I know this one is mentioned on the faq. (Just wanted to know if > > there is any interest) Compilers: Last time anything happened on this front was when I sent a patch to Alan Cox and mentioned that xfs did not build with gcc-2.96-69, he passed this on to Jakob Jelinek at RedHat, he duplicated the problem and was working on it. This was about 10 days ago I have not heard any more since then. So basically, we know that 2.96-69 does not build xfs, I worked around these problems, and got a non-booting kernel. You could try the latest rawhide compiler if you want, but I would not hold out too much hope at the moment. Tree branches: On which xfs to try out, use the development cvs tree if you want the latest changes, the 1.0 tree (not sure of the name) should be a more stable leg and boring leg. We are interested in test results from either. If you do find a problem, please report as much info as you have on hardware used, which tree the code came from and what caused the problem - is it repeatable etc. Thanks Steve > > Ciao, > Michele > -- > Computers are like airconditioners: > They stop working properly if you open windows. From owner-linux-xfs@oss.sgi.com Mon Apr 2 12:44:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32JiaB04505 for linux-xfs-outgoing; Mon, 2 Apr 2001 12:44:36 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32JiaM04502 for ; Mon, 2 Apr 2001 12:44:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05789 for ; Mon, 2 Apr 2001 12:54:48 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1344376 for ; Mon, 2 Apr 2001 14:43:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA20254 for ; Mon, 2 Apr 2001 14:43:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32JfSx06959; Mon, 2 Apr 2001 14:41:28 -0500 Message-Id: <200104021941.f32JfSx06959@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 14:41:28 -0500 Subject: TAKE - narrow down use of GFP_PAGE_IO Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We do not need to use GFP_PAGE_IO in as many places as we were. Date: Mon Apr 2 12:42:15 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/linux-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91398a linux/mm/vmscan.c - 1.52 - Only skip flushing buffers under GFP_PAGE_IO if they are on a delalloc page, this is the only case which matters. linux/fs/xfs/xfs_buf.h - 1.70 - Define BUF_BUSY to be PBF_DONT_BLOCK rather than zero, we can use the info in pagebuf. linux/fs/pagebuf/page_buf.c - 1.68 - Only use GFP_PAGE_IO flag for allocates when the caller passes in the PBF_DONT_BLOCK flag, this corresponds to a call from within the transaction system. From owner-linux-xfs@oss.sgi.com Mon Apr 2 12:55:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32JtZC04773 for linux-xfs-outgoing; Mon, 2 Apr 2001 12:55:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32JtTM04770 for ; Mon, 2 Apr 2001 12:55:29 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07157 for ; Mon, 2 Apr 2001 12:55:29 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA66114 for ; Mon, 2 Apr 2001 14:54:13 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f32Jgdb26796 for ; Mon, 2 Apr 2001 15:42:39 -0400 Message-ID: <3AC8D62E.92349772@thebarn.com> Date: Mon, 02 Apr 2001 15:42:38 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - Bump the development tree to 2.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 10:13:32 PDT 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-newdir The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91381a linux/drivers/net/pcmcia/hermes.h - 1.1 linux/net/ipv4/netfilter/ipt_tcpmss.c - 1.1 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.1 linux/include/net/syncppp.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_tcpmss.h - 1.1 linux/Documentation/SAK.txt - 1.1 linux/include/linux/netfilter_ipv4/ipt_TCPMSS.h - 1.1 linux/include/linux/hdlc.h - 1.1 linux/include/asm-sparc64/dcu.h - 1.1 linux/include/asm-sparc64/dcr.h - 1.1 linux/Documentation/i810_rng.txt - 1.1 linux/include/asm-sparc64/bbc.h - 1.1 linux/include/asm-ppc/tqm8xx.h - 1.1 linux/include/asm-ppc/tlb.h - 1.1 linux/include/asm-ppc/spd8xx.h - 1.1 linux/include/asm-ppc/ivms8.h - 1.1 linux/include/asm-arm/mach/amba_kmi.h - 1.1 linux/include/asm-arm/hardware/amba_kmi.h - 1.1 linux/include/asm-arm/arch-integrator/vmalloc.h - 1.1 linux/include/asm-arm/arch-integrator/uncompress.h - 1.1 linux/include/asm-arm/arch-integrator/timex.h - 1.1 linux/include/asm-arm/arch-integrator/time.h - 1.1 linux/include/asm-arm/arch-integrator/system.h - 1.1 linux/include/asm-arm/arch-integrator/sizes.h - 1.1 linux/include/asm-arm/arch-integrator/serial.h - 1.1 linux/include/asm-arm/arch-integrator/platform.h - 1.1 linux/include/asm-arm/arch-integrator/param.h - 1.1 linux/include/asm-arm/arch-integrator/memory.h - 1.1 linux/include/asm-arm/arch-integrator/keyboard.h - 1.1 linux/include/asm-arm/arch-integrator/irqs.h - 1.1 linux/include/asm-arm/arch-integrator/irq.h - 1.1 linux/include/asm-arm/arch-integrator/io.h - 1.1 linux/include/asm-arm/arch-integrator/hardware.h - 1.1 linux/include/asm-arm/arch-integrator/dma.h - 1.1 linux/include/asm-arm/arch-integrator/bits.h - 1.1 linux/drivers/usb/serial/io_usbvend.h - 1.1 linux/drivers/usb/serial/io_tables.h - 1.1 linux/drivers/usb/serial/io_ionsp.h - 1.1 linux/drivers/usb/serial/io_fw_down2.h - 1.1 linux/drivers/usb/serial/io_fw_down.h - 1.1 linux/drivers/usb/serial/io_fw_boot2.h - 1.1 linux/drivers/usb/serial/io_fw_boot.h - 1.1 linux/drivers/usb/serial/io_edgeport.h - 1.1 linux/drivers/usb/serial/io_edgeport.c - 1.1 linux/drivers/usb/serial/io_16654.h - 1.1 linux/drivers/scsi/aic7xxx_old/sequencer.h - 1.1 linux/drivers/scsi/aic7xxx_old/scsi_message.h - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx_seq.c - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx_reg.h - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx_proc.c - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx.seq - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx.reg - 1.1 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.1 linux/drivers/scsi/aic7xxx_old/README.aic7xxx - 1.1 linux/drivers/scsi/aic7xxx_old.c - 1.1 linux/drivers/scsi/aic7xxx/queue.h - 1.1 linux/drivers/scsi/aic7xxx/cam.h - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_scan.l - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm.h - 1.1 linux/drivers/scsi/aic7xxx/aicasm/aicasm.c - 1.1 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_linux_pci.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_93cx6.c - 1.1 linux/arch/arm/mach-integrator/Makefile - 1.1 linux/arch/arm/mach-integrator/arch.c - 1.1 linux/arch/arm/mach-integrator/dma.c - 1.1 linux/arch/arm/mach-integrator/irq.c - 1.1 linux/arch/arm/mach-integrator/leds.c - 1.1 linux/arch/arm/mach-integrator/mm.c - 1.1 linux/arch/arm/mach-integrator/pci.c - 1.1 linux/arch/arm/mach-integrator/pci_v3.c - 1.1 linux/arch/arm/mach-integrator/time.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.1 linux/drivers/scsi/aic7xxx/aic7770_linux.c - 1.1 linux/drivers/scsi/aic7xxx/aic7770.c - 1.1 linux/drivers/scsi/aic7xxx/Makefile - 1.1 linux/drivers/scsi/aic7xxx/Config.in - 1.1 linux/drivers/sbus/char/riowatchdog.c - 1.1 linux/drivers/net/wan/n2.c - 1.1 linux/drivers/net/wan/hdlc.c - 1.1 linux/drivers/net/wan/hd6457x.c - 1.1 linux/arch/arm/tools/Makefile - 1.1 linux/arch/arm/tools/constants-hdr - 1.1 linux/arch/arm/tools/getconstants.c - 1.1 linux/drivers/net/wan/hd64570.h - 1.1 linux/drivers/net/wan/dscc4.c - 1.1 linux/drivers/net/wan/c101.c - 1.1 linux/drivers/net/sungem.h - 1.1 linux/drivers/net/sungem.c - 1.1 linux/drivers/net/pcmcia/orinoco_cs.c - 1.1 linux/drivers/net/pcmcia/hermes.c - 1.1 linux/drivers/media/radio/radio-maxiradio.c - 1.1 linux/drivers/isdn/hisax/sedlbauer_cs.c - 1.1 linux/drivers/char/machzwd.c - 1.1 linux/drivers/char/advantechwdt.c - 1.1 linux/arch/ppc/configs/TQM860L_defconfig - 1.1 linux/arch/ppc/configs/TQM850L_defconfig - 1.1 linux/arch/ppc/configs/TQM823L_defconfig - 1.1 linux/arch/ppc/configs/SPD823TS_defconfig - 1.1 linux/arch/ppc/configs/SM850_defconfig - 1.1 linux/arch/ppc/configs/IVMS8_defconfig - 1.1 linux/scripts/ver_linux - 1.7 linux/net/wanrouter/wanmain.c - 1.9 linux/net/unix/af_unix.c - 1.27 linux/net/sysctl_net.c - 1.6 linux/net/sunrpc/svcsock.c - 1.13 linux/net/sched/sch_tbf.c - 1.7 linux/net/sched/sch_cbq.c - 1.8 linux/net/sched/Makefile - 1.6 linux/net/netsyms.c - 1.30 linux/net/irda/irlmp_frame.c - 1.7 linux/net/irda/irlmp.c - 1.11 linux/net/irda/irlap_event.c - 1.13 linux/net/irda/irlap_comp.c - 1.5 linux/net/irda/irlap.c - 1.11 linux/net/irda/irlan/irlan_provider.c - 1.6 linux/net/irda/irias_object.c - 1.8 linux/net/irda/ircomm/Makefile - 1.6 linux/net/irda/af_irda.c - 1.18 linux/net/ipx/sysctl_net_ipx.c - 1.3 linux/net/ipx/af_ipx.c - 1.18 linux/net/ipv6/tcp_ipv6.c - 1.22 linux/net/ipv6/reassembly.c - 1.9 linux/net/ipv6/ipv6_sockglue.c - 1.10 linux/net/ipv6/ip6_fib.c - 1.8 linux/net/ipv4/sysctl_net_ipv4.c - 1.11 linux/net/ipv4/ip_fragment.c - 1.12 linux/net/ipv4/devinet.c - 1.11 linux/net/ethernet/eth.c - 1.8 linux/net/core/dev.c - 1.31 linux/net/Config.in - 1.17 linux/mm/vmscan.c - 1.51 linux/mm/vmalloc.c - 1.29 linux/mm/swapfile.c - 1.29 linux/mm/slab.c - 1.23 linux/mm/page_alloc.c - 1.39 linux/mm/mremap.c - 1.21 linux/mm/mprotect.c - 1.15 linux/mm/mmap.c - 1.34 linux/mm/mlock.c - 1.14 linux/mm/memory.c - 1.46 linux/mm/filemap.c - 1.72 linux/lib/vsprintf.c - 1.9 linux/lib/string.c - 1.12 linux/lib/inflate.c - 1.5 linux/kernel/sys.c - 1.19 linux/kernel/sched.c - 1.33 linux/kernel/ksyms.c - 1.82 linux/kernel/fork.c - 1.30 linux/kernel/acct.c - 1.14 linux/ipc/shm.c - 1.47 linux/init/main.c - 1.50 linux/include/net/ipx.h - 1.7 linux/include/linux/videodev.h - 1.13 linux/include/linux/tty.h - 1.15 linux/include/linux/trdevice.h - 1.4 linux/include/linux/tqueue.h - 1.9 linux/include/linux/sysctl.h - 1.31 linux/include/linux/synclink.h - 1.5 linux/include/linux/string.h - 1.8 linux/include/linux/serial_reg.h - 1.5 linux/include/linux/serialP.h - 1.12 linux/include/linux/serial.h - 1.12 linux/include/linux/sched.h - 1.38 linux/include/linux/pg.h - 1.3 linux/include/linux/pci.h - 1.40 linux/include/linux/pagemap.h - 1.24 linux/include/linux/openpic.h - 1.5 linux/include/linux/netdevice.h - 1.21 linux/include/linux/mm.h - 1.51 linux/include/linux/loop.h - 1.3 linux/include/linux/isdn_ppp.h - 1.7 linux/include/linux/init.h - 1.12 linux/include/linux/if_frad.h - 1.5 linux/include/linux/if_eql.h - 1.5 linux/include/linux/if_arp.h - 1.8 linux/include/linux/i2c.h - 1.12 linux/include/linux/hippidevice.h - 1.4 linux/include/linux/genhd.h - 1.11 linux/include/linux/fs.h - 1.86 linux/include/linux/fddidevice.h - 1.5 linux/include/linux/etherdevice.h - 1.6 linux/include/linux/elf.h - 1.12 linux/include/linux/dcache.h - 1.16 linux/include/linux/cdrom.h - 1.17 linux/include/linux/blkdev.h - 1.29 linux/include/linux/b1lli.h - 1.4 linux/include/asm-sparc64/spitfire.h - 1.4 linux/include/asm-sparc64/smp.h - 1.10 linux/include/asm-sparc64/processor.h - 1.16 linux/include/asm-sparc64/pgtable.h - 1.18 linux/include/asm-sparc64/pbm.h - 1.10 linux/include/asm-sparc64/openprom.h - 1.4 linux/include/asm-sparc64/mmu_context.h - 1.8 linux/include/asm-sparc64/irq.h - 1.9 linux/include/asm-sparc64/iommu.h - 1.6 linux/include/asm-sparc64/floppy.h - 1.11 linux/include/asm-sparc64/elf.h - 1.7 linux/include/asm-sparc64/ebus.h - 1.4 linux/include/asm-sparc64/asi.h - 1.3 linux/include/asm-sparc/smp.h - 1.9 linux/include/asm-sparc/semaphore.h - 1.6 linux/include/asm-sparc/atomic.h - 1.7 linux/include/asm-ppc/system.h - 1.17 linux/include/asm-ppc/semaphore.h - 1.6 linux/include/asm-ppc/processor.h - 1.23 linux/include/asm-ppc/irq.h - 1.13 linux/include/asm-i386/system.h - 1.16 linux/include/asm-i386/string.h - 1.9 linux/include/asm-i386/string-486.h - 1.7 linux/include/asm-i386/pgtable.h - 1.26 linux/include/asm-i386/atomic.h - 1.10 linux/include/asm-arm/unistd.h - 1.15 linux/include/asm-arm/uaccess.h - 1.5 linux/include/asm-arm/proc-fns.h - 1.9 linux/include/asm-arm/proc-armv/uaccess.h - 1.7 linux/include/asm-arm/pgtable.h - 1.17 linux/include/asm-arm/param.h - 1.5 linux/include/asm-alpha/smp.h - 1.15 linux/include/asm-alpha/semaphore.h - 1.6 linux/include/asm-alpha/pci.h - 1.12 linux/include/asm-alpha/machvec.h - 1.11 linux/include/asm-alpha/io.h - 1.13 linux/fs/umsdos/emd.c - 1.7 linux/fs/ufs/truncate.c - 1.8 linux/fs/ufs/super.c - 1.16 linux/fs/sysv/inode.c - 1.18 linux/fs/super.c - 1.44 linux/fs/smbfs/proc.c - 1.8 linux/fs/smbfs/inode.c - 1.19 linux/fs/smbfs/cache.c - 1.11 linux/fs/romfs/inode.c - 1.21 linux/fs/qnx4/inode.c - 1.22 linux/fs/proc/inode.c - 1.13 linux/fs/proc/base.c - 1.22 linux/fs/proc/array.c - 1.26 linux/fs/nfsd/vfs.c - 1.33 linux/fs/nfsd/nfssvc.c - 1.12 linux/fs/nfsd/nfsproc.c - 1.14 linux/fs/nfs/inode.c - 1.23 linux/fs/nfs/dir.c - 1.26 linux/fs/ncpfs/mmap.c - 1.13 linux/fs/ncpfs/inode.c - 1.19 linux/fs/ncpfs/dir.c - 1.25 linux/fs/namei.c - 1.25 linux/fs/minix/inode.c - 1.20 linux/fs/isofs/inode.c - 1.22 linux/fs/inode.c - 1.38 linux/fs/hfs/super.c - 1.8 linux/fs/ext2/inode.c - 1.25 linux/fs/ext2/ialloc.c - 1.14 linux/fs/exec.c - 1.40 linux/fs/dcache.c - 1.22 linux/fs/coda/inode.c - 1.12 linux/fs/buffer.c - 1.59 linux/fs/binfmt_elf.c - 1.25 linux/fs/binfmt_aout.c - 1.20 linux/fs/affs/super.c - 1.9 linux/fs/adfs/super.c - 1.10 linux/fs/Makefile - 1.30 linux/drivers/video/sbusfb.c - 1.16 linux/drivers/video/macmodes.c - 1.8 linux/drivers/video/fonts.c - 1.4 linux/drivers/video/fbmem.c - 1.35 linux/drivers/video/fbgen.c - 1.6 linux/drivers/video/fbcmap.c - 1.4 linux/drivers/video/creatorfb.c - 1.8 linux/drivers/video/clgenfb.c - 1.18 linux/drivers/usb/usb.c - 1.46 linux/drivers/usb/uhci.h - 1.22 linux/drivers/usb/uhci.c - 1.41 linux/drivers/usb/hub.h - 1.13 linux/drivers/usb/hub.c - 1.34 linux/drivers/sound/wavfront.c - 1.14 linux/drivers/sound/sonicvibes.c - 1.30 linux/drivers/sound/skeleton.c - 1.5 linux/drivers/sound/opl3sa2.c - 1.8 linux/drivers/sound/msnd_pinnacle.c - 1.15 linux/drivers/sound/gus_midi.c - 1.8 linux/drivers/sound/es1371.c - 1.30 linux/drivers/sound/es1370.c - 1.29 linux/drivers/sound/Config.in - 1.22 linux/drivers/sgi/char/shmiq.c - 1.15 linux/drivers/sgi/char/graphics.c - 1.14 linux/drivers/scsi/sym53c8xx_defs.h - 1.8 linux/drivers/scsi/sym53c8xx.h - 1.6 linux/drivers/scsi/sym53c8xx.c - 1.22 linux/drivers/scsi/sym53c416.c - 1.8 linux/drivers/scsi/scsi_error.c - 1.18 linux/drivers/scsi/qlogicisp.c - 1.19 linux/drivers/scsi/qlogicfc.c - 1.16 linux/drivers/scsi/psi_dale.h - 1.4 linux/drivers/scsi/ppa.h - 1.8 linux/drivers/scsi/ppa.c - 1.10 linux/drivers/scsi/pci2220i.c - 1.16 linux/drivers/scsi/ncr53c8xx.h - 1.4 linux/drivers/scsi/ncr53c8xx.c - 1.19 linux/drivers/scsi/megaraid.h - 1.8 linux/drivers/scsi/megaraid.c - 1.21 linux/drivers/scsi/mac_esp.c - 1.9 linux/drivers/scsi/inia100.h - 1.7 linux/drivers/scsi/inia100.c - 1.15 linux/drivers/scsi/ini9100u.h - 1.7 linux/drivers/scsi/ini9100u.c - 1.14 linux/drivers/scsi/in2000.c - 1.7 linux/drivers/scsi/imm.h - 1.7 linux/drivers/scsi/imm.c - 1.10 linux/drivers/scsi/ibmmca.h - 1.6 linux/drivers/scsi/ibmmca.c - 1.13 linux/drivers/scsi/i91uscsi.h - 1.3 linux/drivers/scsi/i91uscsi.c - 1.4 linux/drivers/scsi/i60uscsi.h - 1.5 linux/drivers/scsi/i60uscsi.c - 1.5 linux/drivers/scsi/g_NCR5380.c - 1.10 linux/drivers/scsi/cyberstormII.c - 1.8 linux/drivers/scsi/cyberstorm.c - 1.8 linux/drivers/scsi/blz2060.c - 1.8 linux/drivers/scsi/blz1230.c - 1.8 linux/drivers/scsi/atari_scsi.c - 1.8 linux/drivers/scsi/atari_dma_emul.c - 1.3 linux/drivers/scsi/aic7xxx_seq.c - 1.6 linux/drivers/scsi/aic7xxx_reg.h - 1.5 linux/drivers/scsi/aic7xxx_proc.c - 1.7 linux/drivers/scsi/aic7xxx/sequencer.h - 1.3 linux/drivers/scsi/aic7xxx/scsi_message.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.7 linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.5 linux/drivers/scsi/aic7xxx.h - 1.5 linux/drivers/scsi/aic7xxx.c - 1.21 linux/drivers/scsi/aha1740.c - 1.6 linux/drivers/scsi/aha1542.h - 1.4 linux/drivers/scsi/aha1542.c - 1.15 linux/drivers/scsi/aha152x.c - 1.18 linux/drivers/scsi/README.aic7xxx - 1.5 linux/drivers/scsi/NCR53c406a.c - 1.7 linux/drivers/scsi/NCR53C9x.c - 1.10 linux/drivers/scsi/Makefile - 1.25 linux/drivers/scsi/Config.in - 1.20 linux/drivers/scsi/ChangeLog.sym53c8xx - 1.12 linux/drivers/scsi/ChangeLog.ncr53c8xx - 1.10 linux/drivers/scsi/AM53C974.c - 1.10 linux/drivers/sbus/sbus.c - 1.12 linux/drivers/sbus/char/vfc_dev.c - 1.12 linux/drivers/sbus/char/sunserial.c - 1.7 linux/drivers/sbus/char/su.c - 1.14 linux/drivers/sbus/char/sab82532.c - 1.16 linux/drivers/sbus/char/rtc.c - 1.10 linux/drivers/sbus/char/pcikbd.c - 1.16 linux/drivers/sbus/char/flash.c - 1.12 linux/drivers/sbus/char/envctrl.c - 1.12 linux/drivers/sbus/char/Makefile - 1.9 linux/drivers/sbus/audio/cs4231.c - 1.10 linux/drivers/sbus/Makefile - 1.6 linux/drivers/pnp/Makefile - 1.10 linux/drivers/pci/pci.c - 1.34 linux/drivers/net/zlib.c - 1.4 linux/drivers/net/yellowfin.c - 1.19 linux/drivers/net/wavelan.p.h - 1.11 linux/drivers/net/wavelan.c - 1.19 linux/drivers/net/via-rhine.c - 1.22 linux/drivers/net/tlan.h - 1.11 linux/drivers/net/tlan.c - 1.18 linux/drivers/net/sunqe.c - 1.16 linux/drivers/net/sunlance.c - 1.21 linux/drivers/net/sunbmac.c - 1.17 linux/drivers/net/sonic.h - 1.7 linux/drivers/net/smc9194.c - 1.12 linux/drivers/net/smc-ultra.c - 1.14 linux/drivers/net/smc-mca.c - 1.11 linux/drivers/net/slhc.c - 1.10 linux/drivers/net/sk_g16.c - 1.10 linux/drivers/net/sgiseeq.c - 1.10 linux/drivers/net/rcpci45.c - 1.17 linux/drivers/net/rclanmtl.h - 1.5 linux/drivers/net/pcnet32.c - 1.22 linux/drivers/net/ni52.h - 1.4 linux/drivers/net/ni5010.c - 1.11 linux/drivers/net/net_init.c - 1.17 linux/drivers/net/ne2k-pci.c - 1.19 linux/drivers/net/ne.c - 1.15 linux/drivers/net/mace.c - 1.11 linux/drivers/net/lance.c - 1.17 linux/drivers/net/irda/w83977af_ir.c - 1.18 linux/drivers/net/irda/irtty.c - 1.20 linux/drivers/net/irda/irport.c - 1.19 linux/drivers/net/hp100.c - 1.17 linux/drivers/net/hamradio/soundmodem/gentbl.c - 1.3 linux/drivers/net/hamradio/scc.c - 1.16 linux/drivers/net/fmv18x.c - 1.12 linux/drivers/net/ewrk3.c - 1.14 linux/drivers/net/eth16i.c - 1.15 linux/drivers/net/eql.c - 1.10 linux/drivers/net/epic100.c - 1.18 linux/drivers/net/eexpress.c - 1.15 linux/drivers/net/eepro.c - 1.17 linux/drivers/net/dgrs_firmware.c - 1.3 linux/drivers/net/dgrs.c - 1.14 linux/drivers/net/depca.c - 1.13 linux/drivers/net/defxx.c - 1.14 linux/drivers/net/de620.c - 1.9 linux/drivers/net/de600.c - 1.10 linux/drivers/net/de4x5.h - 1.4 linux/drivers/net/de4x5.c - 1.19 linux/drivers/net/daynaport.c - 1.9 linux/drivers/net/cs89x0.c - 1.16 linux/drivers/net/atp.c - 1.13 linux/drivers/net/acenic_firmware.h - 1.11 linux/drivers/net/Makefile - 1.40 linux/drivers/net/Config.in - 1.36 linux/drivers/net/82596.c - 1.15 linux/drivers/net/3c59x.c - 1.24 linux/drivers/net/3c527.h - 1.3 linux/drivers/net/3c527.c - 1.16 linux/drivers/net/3c523.h - 1.4 linux/drivers/net/3c515.c - 1.16 linux/drivers/net/3c509.c - 1.19 linux/drivers/net/3c505.c - 1.17 linux/drivers/net/3c503.c - 1.15 linux/drivers/isdn/sc/interrupt.c - 1.3 linux/drivers/isdn/sc/init.c - 1.5 linux/drivers/isdn/pcbit/pcbit.h - 1.6 linux/drivers/isdn/pcbit/module.c - 1.7 linux/drivers/isdn/pcbit/layer2.h - 1.4 linux/drivers/isdn/pcbit/layer2.c - 1.6 linux/drivers/isdn/pcbit/edss1.h - 1.3 linux/drivers/isdn/pcbit/edss1.c - 1.4 linux/drivers/isdn/pcbit/drv.c - 1.11 linux/drivers/isdn/pcbit/capi.h - 1.3 linux/drivers/isdn/pcbit/capi.c - 1.5 linux/drivers/isdn/pcbit/callbacks.h - 1.3 linux/drivers/isdn/pcbit/callbacks.c - 1.4 linux/drivers/isdn/isdnloop/isdnloop.h - 1.6 linux/drivers/isdn/isdnloop/isdnloop.c - 1.5 linux/drivers/isdn/isdn_v110.c - 1.8 linux/drivers/isdn/isdn_tty.c - 1.11 linux/drivers/isdn/isdn_common.c - 1.22 linux/drivers/isdn/isdn_cards.h - 1.4 linux/drivers/isdn/isdn_cards.c - 1.9 linux/drivers/isdn/icn/icn.h - 1.6 linux/drivers/isdn/icn/icn.c - 1.10 linux/drivers/isdn/hisax/teles3.c - 1.11 linux/drivers/isdn/hisax/teles0.c - 1.11 linux/drivers/isdn/hisax/teleint.c - 1.10 linux/drivers/isdn/hisax/tei.c - 1.7 linux/drivers/isdn/hisax/sportster.c - 1.10 linux/drivers/isdn/hisax/sedlbauer.c - 1.14 linux/drivers/isdn/hisax/rawhdlc.h - 1.4 linux/drivers/isdn/hisax/rawhdlc.c - 1.5 linux/drivers/isdn/hisax/q931.c - 1.5 linux/drivers/isdn/hisax/niccy.c - 1.12 linux/drivers/isdn/hisax/netjet.c - 1.15 linux/drivers/isdn/hisax/mic.c - 1.9 linux/drivers/isdn/hisax/lmgr.c - 1.5 linux/drivers/isdn/hisax/l3dss1.h - 1.6 linux/drivers/isdn/hisax/l3dss1.c - 1.11 linux/drivers/isdn/hisax/l3_1tr6.h - 1.4 linux/drivers/isdn/hisax/l3_1tr6.c - 1.8 linux/drivers/isdn/hisax/ix1_micro.c - 1.9 linux/drivers/isdn/hisax/isdnl3.h - 1.5 linux/drivers/isdn/hisax/isdnl3.c - 1.10 linux/drivers/isdn/hisax/isdnl2.h - 1.4 linux/drivers/isdn/hisax/isdnl2.c - 1.9 linux/drivers/isdn/hisax/isdnl1.h - 1.4 linux/drivers/isdn/hisax/isdnl1.c - 1.10 linux/drivers/isdn/hisax/isac.h - 1.5 linux/drivers/isdn/hisax/isac.c - 1.9 linux/drivers/isdn/hisax/ipac.h - 1.5 linux/drivers/isdn/hisax/hscx_irq.c - 1.8 linux/drivers/isdn/hisax/hscx.h - 1.5 linux/drivers/isdn/hisax/hscx.c - 1.8 linux/drivers/isdn/hisax/hisax.h - 1.15 linux/drivers/isdn/hisax/hfc_2bs0.h - 1.5 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.11 linux/drivers/isdn/hisax/hfc_2bds0.h - 1.5 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.11 linux/drivers/isdn/hisax/fsm.c - 1.7 linux/drivers/isdn/hisax/elsa.c - 1.11 linux/drivers/isdn/hisax/diva.c - 1.13 linux/drivers/isdn/hisax/config.c - 1.16 linux/drivers/isdn/hisax/callc.c - 1.11 linux/drivers/isdn/hisax/avm_a1.c - 1.9 linux/drivers/isdn/hisax/asuscom.c - 1.10 linux/drivers/isdn/hisax/arcofi.h - 1.6 linux/drivers/isdn/hisax/arcofi.c - 1.9 linux/drivers/isdn/hisax/amd7930.c - 1.9 linux/drivers/isdn/hisax/Makefile - 1.10 linux/drivers/isdn/avmb1/capiutil.c - 1.7 linux/drivers/isdn/avmb1/capidrv.c - 1.15 linux/drivers/isdn/avmb1/capi.c - 1.19 linux/drivers/isdn/avmb1/b1pci.c - 1.11 linux/drivers/isdn/act2000/module.c - 1.6 linux/drivers/isdn/act2000/capi.h - 1.5 linux/drivers/isdn/act2000/capi.c - 1.5 linux/drivers/isdn/act2000/act2000.h - 1.5 linux/drivers/isdn/Makefile - 1.8 linux/drivers/isdn/Config.in - 1.15 linux/drivers/fc4/Makefile - 1.6 linux/drivers/char/tty_io.c - 1.28 linux/drivers/char/tpqic02.c - 1.12 linux/drivers/char/synclink.c - 1.13 linux/drivers/char/stallion.c - 1.15 linux/drivers/char/serial.c - 1.37 linux/drivers/char/rocket.c - 1.11 linux/drivers/char/pc_keyb.c - 1.21 linux/drivers/char/misc.c - 1.23 linux/drivers/char/mem.c - 1.33 linux/drivers/char/lp.c - 1.19 linux/drivers/char/istallion.c - 1.15 linux/drivers/char/dsp56k.c - 1.13 linux/drivers/char/Makefile - 1.41 linux/drivers/char/Config.in - 1.42 linux/drivers/cdrom/cdrom.c - 1.30 linux/drivers/block/nbd.c - 1.17 linux/drivers/block/loop.c - 1.29 linux/drivers/block/ll_rw_blk.c - 1.64 linux/drivers/acorn/scsi/powertec.c - 1.8 linux/drivers/acorn/scsi/eesox.c - 1.7 linux/drivers/acorn/scsi/cumana_2.c - 1.7 linux/drivers/acorn/scsi/acornscsi.c - 1.6 linux/arch/sparc64/solaris/misc.c - 1.18 linux/arch/sparc64/mm/ultra.S - 1.15 linux/arch/sparc64/mm/init.c - 1.23 linux/arch/sparc64/mm/generic.c - 1.7 linux/arch/sparc64/mm/fault.c - 1.15 linux/arch/sparc64/lib/blockops.S - 1.10 linux/arch/sparc64/lib/VISsave.S - 1.4 linux/arch/sparc64/lib/VISbzero.S - 1.3 linux/arch/sparc64/kernel/unaligned.c - 1.6 linux/arch/sparc64/kernel/ttable.S - 1.7 linux/arch/sparc64/kernel/traps.c - 1.12 linux/arch/sparc64/kernel/trampoline.S - 1.6 linux/arch/sparc64/kernel/time.c - 1.12 linux/arch/sparc64/kernel/sys_sunos32.c - 1.28 linux/arch/sparc64/kernel/sys_sparc32.c - 1.34 linux/arch/sparc64/kernel/sys_sparc.c - 1.19 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.26 linux/arch/sparc64/kernel/smp.c - 1.22 linux/arch/sparc64/kernel/signal32.c - 1.16 linux/arch/sparc64/kernel/signal.c - 1.15 linux/arch/sparc64/kernel/setup.c - 1.17 linux/arch/sparc64/kernel/rtrap.S - 1.7 linux/arch/sparc64/kernel/ptrace.c - 1.8 linux/arch/sparc64/kernel/process.c - 1.18 linux/arch/sparc64/kernel/irq.c - 1.17 linux/arch/sparc64/kernel/ioctl32.c - 1.32 linux/arch/sparc64/kernel/head.S - 1.7 linux/arch/sparc64/kernel/etrap.S - 1.5 linux/arch/sparc64/kernel/entry.S - 1.12 linux/arch/sparc64/kernel/ebus.c - 1.11 linux/arch/sparc64/kernel/dtlb_base.S - 1.6 linux/arch/sparc64/kernel/devices.c - 1.7 linux/arch/sparc64/kernel/cpu.c - 1.6 linux/arch/sparc64/kernel/binfmt_aout32.c - 1.15 linux/arch/sparc64/kernel/auxio.c - 1.6 linux/arch/sparc64/kernel/Makefile - 1.17 linux/arch/sparc64/defconfig - 1.33 linux/arch/sparc64/config.in - 1.36 linux/arch/sparc/mm/sun4c.c - 1.25 linux/arch/sparc/mm/srmmu.c - 1.23 linux/arch/sparc/mm/init.c - 1.23 linux/arch/sparc/mm/fault.c - 1.14 linux/arch/sparc/kernel/sys_sunos.c - 1.27 linux/arch/sparc/kernel/sys_sparc.c - 1.13 linux/arch/sparc/kernel/ptrace.c - 1.8 linux/arch/sparc/defconfig - 1.21 linux/arch/ppc/mm/init.c - 1.32 linux/arch/ppc/mm/fault.c - 1.14 linux/arch/ppc/kernel/traps.c - 1.17 linux/arch/ppc/kernel/time.c - 1.12 linux/arch/ppc/kernel/syscalls.c - 1.9 linux/arch/ppc/kernel/softemu8xx.c - 1.5 linux/arch/ppc/kernel/smp.c - 1.23 linux/arch/ppc/kernel/setup.c - 1.30 linux/arch/ppc/kernel/prom.c - 1.19 linux/arch/ppc/kernel/prep_setup.c - 1.17 linux/arch/ppc/kernel/prep_pci.c - 1.8 linux/arch/ppc/kernel/ppc_ksyms.c - 1.29 linux/arch/ppc/kernel/ppc8xx_pic.c - 1.6 linux/arch/ppc/kernel/pmac_setup.c - 1.20 linux/arch/ppc/kernel/pmac_pci.c - 1.12 linux/arch/ppc/kernel/pci.c - 1.18 linux/arch/ppc/kernel/open_pic.c - 1.17 linux/arch/ppc/kernel/irq.c - 1.26 linux/arch/ppc/kernel/head.S - 1.24 linux/arch/ppc/kernel/chrp_setup.c - 1.19 linux/arch/ppc/kernel/chrp_pci.c - 1.15 linux/arch/ppc/kernel/Makefile - 1.19 linux/arch/ppc/defconfig - 1.28 linux/arch/ppc/config.in - 1.33 linux/arch/ppc/8xx_io/uart.c - 1.12 linux/arch/ppc/8xx_io/fec.c - 1.12 linux/arch/ppc/8xx_io/enet.c - 1.12 linux/arch/ppc/8xx_io/commproc.h - 1.7 linux/arch/ppc/8xx_io/commproc.c - 1.7 linux/arch/mips/sgi/kernel/setup.c - 1.9 linux/arch/mips/sgi/kernel/indy_sc.c - 1.8 linux/arch/mips/mm/umap.c - 1.6 linux/arch/mips/mm/fault.c - 1.10 linux/arch/mips/kernel/sysirix.c - 1.14 linux/arch/mips/kernel/syscall.c - 1.8 linux/arch/mips/kernel/mips_ksyms.c - 1.9 linux/arch/mips/kernel/irixelf.c - 1.15 linux/arch/mips/defconfig - 1.16 linux/arch/m68k/q40/config.c - 1.8 linux/arch/m68k/q40/README - 1.5 linux/arch/m68k/mm/fault.c - 1.9 linux/arch/m68k/kernel/sys_m68k.c - 1.7 linux/arch/m68k/kernel/ints.c - 1.6 linux/arch/m68k/kernel/head.S - 1.5 linux/arch/m68k/kernel/bios32.c - 1.7 linux/arch/m68k/apollo/dn_ints.c - 1.5 linux/arch/i386/mm/ioremap.c - 1.9 linux/arch/i386/mm/init.c - 1.28 linux/arch/i386/mm/fault.c - 1.16 linux/arch/i386/mm/extable.c - 1.4 linux/arch/i386/kernel/sys_i386.c - 1.7 linux/arch/i386/kernel/setup.c - 1.44 linux/arch/i386/kernel/ptrace.c - 1.13 linux/arch/i386/kernel/ldt.c - 1.7 linux/arch/i386/kernel/i386_ksyms.c - 1.35 linux/arch/i386/kernel/head.S - 1.17 linux/arch/i386/defconfig - 1.53 linux/arch/arm/mm/proc-sa110.S - 1.19 linux/arch/arm/mm/proc-arm6,7.S - 1.17 linux/arch/arm/mm/proc-arm2,3.S - 1.9 linux/arch/arm/mm/mm-rpc.c - 1.9 linux/arch/arm/mm/fault-common.c - 1.14 linux/arch/arm/lib/memcpy.S - 1.7 linux/arch/arm/lib/getconsdata.c - 1.9 linux/arch/arm/lib/extractconstants.pl - 1.3 linux/arch/arm/lib/Makefile - 1.15 linux/arch/arm/kernel/sys_arm.c - 1.16 linux/arch/arm/kernel/entry-common.S - 1.13 linux/arch/arm/kernel/entry-armv.S - 1.17 linux/arch/arm/kernel/entry-armo.S - 1.10 linux/arch/alpha/mm/fault.c - 1.13 linux/arch/alpha/kernel/sys_rawhide.c - 1.10 linux/arch/alpha/kernel/sys_jensen.c - 1.9 linux/arch/alpha/kernel/sys_dp264.c - 1.13 linux/arch/alpha/kernel/setup.c - 1.19 linux/arch/alpha/kernel/proto.h - 1.16 linux/arch/alpha/kernel/osf_sys.c - 1.23 linux/arch/alpha/kernel/core_tsunami.c - 1.16 linux/arch/alpha/kernel/core_t2.c - 1.10 linux/arch/alpha/kernel/core_polaris.c - 1.11 linux/arch/alpha/kernel/core_mcpcia.c - 1.16 linux/arch/alpha/kernel/core_lca.c - 1.11 linux/arch/alpha/kernel/core_cia.c - 1.17 linux/arch/alpha/kernel/core_apecs.c - 1.11 linux/arch/alpha/kernel/alpha_ksyms.c - 1.19 linux/arch/alpha/defconfig - 1.15 linux/Rules.make - 1.13 linux/README - 1.10 linux/Makefile - 1.84 linux/MAINTAINERS - 1.56 linux/Documentation/sysrq.txt - 1.9 linux/Documentation/sysctl/vm.txt - 1.5 linux/Documentation/powerpc/zImage_layout.txt - 1.3 linux/Documentation/powerpc/sound.txt - 1.4 linux/Documentation/powerpc/smp.txt - 1.3 linux/Documentation/powerpc/ppc_htab.txt - 1.3 linux/Documentation/parport.txt - 1.11 linux/Documentation/networking/vortex.txt - 1.8 linux/Documentation/networking/tulip.txt - 1.9 linux/Documentation/networking/tlan.txt - 1.8 linux/Documentation/networking/ip-sysctl.txt - 1.8 linux/Documentation/networking/cs89x0.txt - 1.8 linux/Documentation/isdn/INTERFACE - 1.6 linux/Documentation/isdn/00-INDEX - 1.6 linux/Documentation/ioctl-number.txt - 1.16 linux/Documentation/binfmt_misc.txt - 1.3 linux/Documentation/Configure.help - 1.75 linux/Documentation/Changes - 1.35 linux/CREDITS - 1.50 linux/net/decnet/af_decnet.c - 1.22 linux/fs/hpfs/super.c - 1.7 linux/fs/efs/super.c - 1.7 linux/drivers/usb/printer.c - 1.34 linux/drivers/sbus/char/aurora.c - 1.7 linux/drivers/net/irda/smc-ircc.c - 1.18 linux/drivers/isdn/isdn_bsdcomp.c - 1.4 linux/drivers/isdn/hisax/telespci.c - 1.10 linux/drivers/isdn/hisax/s0box.c - 1.7 linux/drivers/isdn/hisax/isar.h - 1.7 linux/drivers/isdn/hisax/isar.c - 1.10 linux/drivers/isdn/hisax/elsa_ser.c - 1.7 linux/drivers/isdn/hisax/cert.c - 1.4 linux/drivers/isdn/hisax/avm_pci.c - 1.10 linux/drivers/isdn/hisax/avm_a1p.c - 1.7 linux/drivers/isdn/eicon/eicon_pci.c - 1.8 linux/drivers/isdn/eicon/eicon_mod.c - 1.12 linux/drivers/isdn/eicon/eicon_io.c - 1.7 linux/drivers/isdn/eicon/eicon_idi.c - 1.10 linux/drivers/isdn/eicon/eicon.h - 1.9 linux/drivers/isdn/eicon/Makefile - 1.5 linux/arch/arm/nwfpe/entry26.S - 1.3 linux/Documentation/kernel-parameters.txt - 1.11 linux/Documentation/isdn/README.eicon - 1.8 linux/drivers/net/jazzsonic.c - 1.6 linux/drivers/net/declance.c - 1.9 linux/drivers/char/dz.c - 1.10 linux/arch/mips/dec/prom/memory.c - 1.7 linux/arch/mips/boot/elf2ecoff.c - 1.3 linux/arch/mips/baget/irq.c - 1.7 linux/drivers/net/arlan.h - 1.7 linux/drivers/net/arlan.c - 1.15 linux/drivers/net/arlan-proc.c - 1.6 linux/kernel/ptrace.c - 1.12 linux/fs/iobuf.c - 1.16 linux/drivers/parport/share.c - 1.14 linux/drivers/parport/parport_pc.c - 1.31 linux/drivers/parport/ieee1284_ops.c - 1.10 linux/include/asm-sparc64/parport.h - 1.9 linux/drivers/net/macsonic.c - 1.6 linux/drivers/char/sx.c - 1.16 linux/drivers/usb/uss720.c - 1.17 linux/drivers/sound/esssolo1.c - 1.26 linux/net/khttpd/rfc.c - 1.4 linux/net/khttpd/main.c - 1.8 linux/drivers/scsi/sun3x_esp.c - 1.4 linux/drivers/isdn/hisax/saphir.c - 1.8 linux/drivers/isdn/hisax/jade_irq.c - 1.6 linux/drivers/isdn/hisax/jade.h - 1.3 linux/drivers/isdn/hisax/jade.c - 1.6 linux/drivers/isdn/hisax/isurf.c - 1.9 linux/drivers/isdn/hisax/hfcscard.c - 1.7 linux/drivers/isdn/hisax/hfc_pci.c - 1.14 linux/drivers/isdn/hisax/gazel.c - 1.8 linux/drivers/isdn/hisax/bkm_ax.h - 1.4 linux/drivers/isdn/hisax/bkm_a8.c - 1.8 linux/drivers/isdn/hisax/bkm_a4t.c - 1.9 linux/drivers/isdn/divert/isdn_divert.c - 1.6 linux/drivers/isdn/divert/divert_init.c - 1.4 linux/drivers/isdn/avmb1/t1isa.c - 1.10 linux/drivers/isdn/avmb1/kcapi.c - 1.11 linux/drivers/isdn/avmb1/b1pcmcia.c - 1.10 linux/drivers/isdn/avmb1/b1isa.c - 1.8 linux/drivers/isdn/avmb1/b1.c - 1.10 linux/drivers/video/modedb.c - 1.4 linux/drivers/net/sis900.c - 1.20 linux/drivers/net/sb1000.c - 1.11 linux/drivers/net/fc/iph5526.c - 1.12 linux/drivers/atm/nicstar.c - 1.13 linux/drivers/atm/Makefile - 1.12 linux/net/atm/proc.c - 1.12 linux/net/atm/lec.c - 1.12 linux/net/atm/Makefile - 1.8 linux/include/linux/fcdevice.h - 1.2 linux/arch/ppc/kernel/head_8xx.S - 1.9 linux/arch/arm/vmlinux-armv.lds.in - 1.13 linux/arch/alpha/kernel/pci_impl.h - 1.7 linux/arch/alpha/kernel/pci.c - 1.14 linux/arch/sparc64/kernel/pci_sabre.c - 1.17 linux/arch/sparc64/kernel/pci_psycho.c - 1.15 linux/arch/sparc64/kernel/pci_iommu.c - 1.9 linux/arch/sparc64/kernel/pci_common.c - 1.9 linux/arch/sparc64/kernel/pci.c - 1.17 linux/arch/sh/mm/fault.c - 1.14 linux/arch/sh/kernel/sys_sh.c - 1.7 linux/arch/sh/kernel/sh_ksyms.c - 1.7 linux/drivers/sound/maestro.c - 1.21 linux/drivers/scsi/ips.c - 1.14 linux/net/irda/ircomm/ircomm_tty.c - 1.12 linux/net/irda/ircomm/ircomm_ttp.c - 1.5 linux/net/irda/ircomm/ircomm_lmp.c - 1.4 linux/net/irda/ircomm/ircomm_event.c - 1.5 linux/net/irda/ircomm/ircomm_core.c - 1.10 linux/include/linux/n_r3964.h - 1.2 linux/include/asm-i386/pci.h - 1.7 linux/drivers/pcmcia/tcic.c - 1.12 linux/drivers/pcmcia/rsrc_mgr.c - 1.12 linux/drivers/pcmcia/i82365.c - 1.17 linux/drivers/pcmcia/cardbus.c - 1.17 linux/drivers/pcmcia/bulkmem.c - 1.13 linux/drivers/pcmcia/Makefile - 1.9 linux/drivers/net/sun3lance.c - 1.6 linux/include/pcmcia/ciscode.h - 1.6 linux/fs/udf/super.c - 1.17 linux/include/asm-ppc/pci.h - 1.10 linux/drivers/net/pcmcia/ray_cs.c - 1.19 linux/drivers/net/pcmcia/pcnet_cs.c - 1.13 linux/drivers/net/pcmcia/Makefile - 1.15 linux/drivers/net/pcmcia/Config.in - 1.21 linux/drivers/net/pcmcia/3c589_cs.c - 1.14 linux/drivers/char/drm/drmP.h - 1.11 linux/drivers/char/drm/bufs.c - 1.8 linux/drivers/char/drm/Makefile - 1.10 linux/drivers/net/dmfe.c - 1.12 linux/drivers/net/wan/cosa.h - 1.2 linux/drivers/net/wan/cosa.c - 1.18 linux/drivers/net/wan/Makefile - 1.10 linux/drivers/net/wan/Config.in - 1.9 linux/drivers/net/tokenring/olympic.h - 1.6 linux/drivers/net/tokenring/olympic.c - 1.11 linux/drivers/net/tokenring/ibmtr.c - 1.12 linux/drivers/net/tokenring/Config.in - 1.9 linux/arch/ppc/kernel/m8xx_setup.c - 1.10 linux/arch/ppc/8xx_io/Config.in - 1.3 linux/arch/i386/lib/mmx.c - 1.5 linux/arch/i386/kernel/pci-pc.c - 1.21 linux/include/linux/pci_ids.h - 1.33 linux/drivers/net/wan/z85230.c - 1.9 linux/drivers/net/wan/syncppp.h - 1.4 linux/drivers/net/wan/syncppp.c - 1.8 linux/drivers/net/wan/sealevel.c - 1.7 linux/drivers/net/wan/sdlamain.c - 1.7 linux/drivers/net/wan/sdladrv.c - 1.5 linux/drivers/net/wan/sdla_x25.c - 1.5 linux/drivers/net/wan/sdla_ppp.c - 1.8 linux/drivers/net/wan/sdla_fr.c - 1.9 linux/drivers/net/wan/sbni.c - 1.9 linux/drivers/net/wan/hostess_sv11.c - 1.7 linux/drivers/net/wan/dlci.c - 1.6 linux/drivers/net/wan/cycx_x25.c - 1.11 linux/include/asm-ppc/mpc8xx.h - 1.5 linux/drivers/net/tokenring/tms380tr.h - 1.4 linux/drivers/net/tokenring/tms380tr.c - 1.14 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.12 linux/Documentation/arm/SA1100/Brutus - 1.5 linux/drivers/net/pcmcia/3c574_cs.c - 1.12 linux/drivers/net/pcmcia/nmclan_cs.c - 1.10 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.9 linux/drivers/net/pcmcia/netwave_cs.c - 1.13 linux/drivers/net/pcmcia/i82593.h - 1.2 linux/arch/arm/mm/mm-sa1100.c - 1.9 linux/drivers/net/pcmcia/wavelan_cs.h - 1.7 linux/drivers/net/pcmcia/wavelan_cs.c - 1.8 linux/drivers/net/pcmcia/wavelan.h - 1.2 linux/Documentation/vm/locking - 1.6 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.10 linux/include/asm-i386/pgtable-3level.h - 1.6 linux/include/asm-i386/highmem.h - 1.7 linux/include/asm-arm/arch-sa1100/irq.h - 1.6 linux/fs/proc/proc_misc.c - 1.17 linux/fs/bfs/inode.c - 1.13 linux/drivers/usb/dc2xx.c - 1.16 linux/drivers/isdn/avmb1/t1pci.c - 1.10 linux/drivers/char/pcmcia/serial_cb.c - 1.7 linux/drivers/char/pcmcia/Makefile - 1.4 linux/drivers/char/pcmcia/Config.in - 1.6 linux/drivers/isdn/hisax/w6692.h - 1.3 linux/drivers/isdn/hisax/w6692.c - 1.8 linux/drivers/scsi/sun3_scsi.c - 1.7 linux/drivers/pci/pci.ids - 1.27 linux/drivers/net/sk98lin/skxmac2.c - 1.3 linux/drivers/net/sk98lin/skgepnmi.c - 1.3 linux/drivers/net/sk98lin/skgesirq.c - 1.3 linux/drivers/net/sk98lin/h/lm80.h - 1.3 linux/drivers/net/sk98lin/h/skgehw.h - 1.3 linux/drivers/net/sk98lin/skgeinit.c - 1.3 linux/drivers/net/sk98lin/skge.c - 1.9 linux/drivers/net/sk98lin/skqueue.c - 1.3 linux/drivers/net/sk98lin/ski2c.c - 1.3 linux/drivers/net/sk98lin/h/xmac_ii.h - 1.3 linux/include/asm-ppc/pgalloc.h - 1.5 linux/include/asm-i386/pgalloc.h - 1.8 linux/include/asm-i386/pgalloc-3level.h - 1.3 linux/include/asm-i386/pgalloc-2level.h - 1.2 linux/arch/ppc/treeboot/mkevimg - 1.3 linux/arch/ppc/configs/common_defconfig - 1.16 linux/arch/alpha/kernel/sys_nautilus.c - 1.6 linux/arch/alpha/kernel/sys_eiger.c - 1.5 linux/arch/alpha/kernel/core_irongate.c - 1.6 linux/include/linux/mmzone.h - 1.13 linux/drivers/sound/trident.c - 1.20 linux/include/linux/802_11.h - 1.2 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.10 linux/drivers/net/aironet4500_card.c - 1.10 linux/drivers/char/agp/agpgart_fe.c - 1.8 linux/drivers/char/agp/Makefile - 1.5 linux/drivers/scsi/scsi_lib.c - 1.28 linux/drivers/i2c/i2c-algo-bit.c - 1.7 linux/include/asm-sparc64/pgalloc.h - 1.10 linux/fs/cramfs/inode.c - 1.14 linux/drivers/usb/scanner.c - 1.19 linux/drivers/usb/ov511.c - 1.20 linux/drivers/telephony/ixj.c - 1.12 linux/drivers/net/arcnet/com20020-pci.c - 1.7 linux/drivers/net/arcnet/arcnet.c - 1.9 linux/drivers/net/arcnet/Config.in - 1.2 linux/Documentation/usb/usb-serial.txt - 1.15 linux/drivers/net/tokenring/smctr.c - 1.9 linux/net/sched/sch_dsmark.c - 1.6 linux/net/sched/cls_tcindex.c - 1.4 linux/drivers/net/oaknet.c - 1.7 linux/drivers/usb/devio.c - 1.13 linux/drivers/usb/inode.c - 1.12 linux/drivers/ieee1394/pcilynx.c - 1.8 linux/drivers/ieee1394/ieee1394_core.c - 1.7 linux/drivers/ieee1394/ohci1394.h - 1.9 linux/drivers/ieee1394/ohci1394.c - 1.11 linux/arch/arm/lib/copy_page.S - 1.4 linux/arch/arm/lib/csumpartialcopyuser.S - 1.4 linux/drivers/ieee1394/csr.h - 1.3 linux/drivers/ieee1394/csr.c - 1.5 linux/drivers/char/mxser.c - 1.7 linux/drivers/ieee1394/aic5800.c - 1.5 linux/drivers/scsi/3w-xxxx.h - 1.4 linux/drivers/scsi/3w-xxxx.c - 1.8 linux/drivers/net/wan/sdla_chdlc.c - 1.8 linux/Documentation/DMA-mapping.txt - 1.7 linux/drivers/usb/usb-uhci.c - 1.18 linux/drivers/usb/usb-ohci.h - 1.8 linux/drivers/usb/usb-ohci.c - 1.18 linux/drivers/usb/scanner.h - 1.12 linux/drivers/net/irda/nsc-ircc.c - 1.12 linux/drivers/net/mac89x0.c - 1.5 linux/drivers/net/macmace.c - 1.3 linux/drivers/acorn/char/pcf8583.c - 1.4 linux/arch/ia64/ia32/sys_ia32.c - 1.14 linux/arch/ia64/ia32/binfmt_elf32.c - 1.9 linux/drivers/acorn/char/i2c.c - 1.3 linux/arch/alpha/kernel/pci_iommu.c - 1.11 linux/arch/ia64/kernel/sys_ia64.c - 1.6 linux/arch/ia64/lib/copy_user.S - 1.7 linux/arch/ia64/mm/fault.c - 1.5 linux/arch/ia64/lib/strlen.S - 1.4 linux/arch/ia64/lib/strlen_user.S - 1.3 linux/drivers/sound/via82cxxx_audio.c - 1.13 linux/drivers/scsi/qla1280.c - 1.8 linux/kernel/pm.c - 1.7 linux/include/asm-ia64/system.h - 1.7 linux/drivers/net/rtl8129.c - 1.7 linux/drivers/net/8139too.c - 1.17 linux/drivers/isdn/avmb1/c4.c - 1.10 linux/drivers/isdn/avmb1/b1dma.c - 1.11 linux/Documentation/isdn/README.hysdn - 1.4 linux/include/linux/hysdn_if.h - 1.2 linux/drivers/usb/plusb.c - 1.9 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.5 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.5 linux/drivers/isdn/hysdn/hysdn_init.c - 1.7 linux/drivers/isdn/hysdn/hysdn_net.c - 1.5 linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.8 linux/drivers/isdn/hysdn/hysdn_procfs.c - 1.5 linux/drivers/isdn/hysdn/hysdn_sched.c - 1.5 linux/drivers/scsi/pcmcia/Config.in - 1.2 linux/drivers/scsi/pcmcia/Makefile - 1.4 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.5 linux/drivers/scsi/pcmcia/apa1480_stub.c - 1.4 linux/drivers/isdn/hysdn/boardergo.c - 1.7 linux/drivers/isdn/hysdn/hysdn_boot.c - 1.5 linux/drivers/net/skfp/srf.c - 1.3 linux/drivers/net/skfp/pcmplc.c - 1.2 linux/drivers/net/skfp/skfddi.c - 1.9 linux/drivers/net/skfp/drvfbi.c - 1.3 linux/drivers/net/skfp/fplustm.c - 1.4 linux/drivers/net/skfp/h/smc.h - 1.2 linux/drivers/net/skfp/h/skfbi.h - 1.2 linux/Documentation/networking/8139too.txt - 1.8 linux/drivers/net/tulip/tulip_core.c - 1.19 linux/drivers/net/tulip/tulip.h - 1.10 linux/drivers/net/tulip/pnic.c - 1.5 linux/drivers/net/tulip/media.c - 1.7 linux/drivers/net/tulip/interrupt.c - 1.8 linux/drivers/net/ioc3-eth.c - 1.10 linux/arch/mips64/defconfig - 1.11 linux/arch/mips64/mm/umap.c - 1.4 linux/arch/mips64/mm/fault.c - 1.6 linux/arch/mips64/kernel/syscall.c - 1.7 linux/arch/mips64/sgi-ip22/ip22-sc.c - 1.4 linux/arch/mips64/kernel/linux32.c - 1.8 linux/arch/mips64/kernel/mips64_ksyms.c - 1.5 linux/drivers/net/bonding.c - 1.5 linux/include/linux/if_bonding.h - 1.2 linux/drivers/usb/pegasus.c - 1.15 linux/drivers/net/appletalk/cops.c - 1.9 linux/include/linux/usb.h - 1.14 linux/drivers/usb/serial/Makefile - 1.13 linux/drivers/sound/awe_wave.c - 1.7 linux/drivers/parport/ChangeLog - 1.12 linux/drivers/ide/piix.c - 1.9 linux/drivers/ide/pdc4030.c - 1.5 linux/drivers/ide/ide.c - 1.19 linux/drivers/ide/ide-probe.c - 1.14 linux/drivers/scsi/sym53c8xx_comm.h - 1.7 linux/drivers/net/wan/comx.c - 1.9 linux/drivers/net/wan/comx-proto-ppp.c - 1.3 linux/drivers/net/wan/comx-proto-lapb.c - 1.5 linux/drivers/net/wan/comx-proto-fr.c - 1.4 linux/drivers/net/tokenring/lanstreamer.h - 1.3 linux/drivers/net/tokenring/lanstreamer.c - 1.5 linux/Documentation/DocBook/kernel-api.tmpl - 1.8 linux/net/ipv4/netfilter/Makefile - 1.7 linux/net/ipv4/netfilter/Config.in - 1.4 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.10 linux/drivers/isdn/avmb1/capifs.c - 1.9 linux/drivers/isdn/avmb1/avm_cs.c - 1.5 linux/drivers/scsi/dmx3191d.c - 1.5 linux/drivers/usb/serial/ftdi_sio.c - 1.13 linux/drivers/usb/serial/usbserial.c - 1.13 linux/drivers/usb/serial/whiteheat.c - 1.11 linux/drivers/usb/serial/visor.c - 1.13 linux/drivers/usb/serial/omninet.c - 1.10 linux/drivers/sound/i810_audio.c - 1.9 linux/drivers/sound/emu10k1/main.c - 1.8 linux/drivers/net/wan/lmc/lmc_var.h - 1.4 linux/drivers/net/wan/lmc/lmc_proto.c - 1.3 linux/drivers/net/wan/lmc/lmc_media.c - 1.3 linux/drivers/net/wan/lmc/lmc_main.c - 1.6 linux/include/linux/fs_struct.h - 1.4 linux/include/asm-ppc/cpm_8260.h - 1.5 linux/drivers/usb/serial/digi_acceleport.c - 1.10 linux/drivers/net/pppoe.c - 1.11 linux/arch/ppc/kernel/m8260_setup.c - 1.6 linux/include/asm-s390/lowcore.h - 1.4 linux/arch/s390/kernel/entry.S - 1.7 linux/drivers/s390/net/ctc.c - 1.4 linux/Documentation/s390/cds.txt - 1.5 linux/arch/s390/kernel/sys_s390.c - 1.4 linux/arch/s390/tools/dasdfmt/dasdfmt.c - 1.3 linux/arch/s390/mm/fault.c - 1.4 linux/Documentation/kernel-doc-nano-HOWTO.txt - 1.3 linux/include/asm-mips64/smp.h - 1.3 linux/include/linux/kdb.h - 1.16 linux/kdb/kdbsupport.c - 1.10 linux/kdb/kdbmain.c - 1.19 linux/include/linux/dis-asm.h - 1.7 linux/arch/i386/kdb/kdbasupport.c - 1.14 linux/arch/i386/kdb/kdba_io.c - 1.12 linux/kernel/kallsyms.c - 1.10 linux/include/linux/kallsyms.h - 1.8 linux/kdb/modules/kdbm_pg.c - 1.31 linux/drivers/char/i810_rng.c - 1.5 linux/drivers/char/drm/r128_drv.h - 1.4 linux/drivers/char/drm/r128_bufs.c - 1.4 linux/drivers/char/drm/mga_bufs.c - 1.4 linux/drivers/char/drm/i810_dma.c - 1.5 linux/drivers/char/drm/ffb_drv.c - 1.4 linux/include/asm-ppc/time.h - 1.4 linux/include/asm-ppc/tqm860.h - 1.3 linux/drivers/usb/storage/usb.h - 1.7 linux/arch/alpha/kernel/console.c - 1.2 linux/arch/alpha/kernel/core_titan.c - 1.2 linux/arch/alpha/kernel/core_wildfire.c - 1.2 linux/include/asm-ppc/tqm8xxL.h - 1.3 linux/arch/alpha/kernel/sys_titan.c - 1.2 linux/arch/alpha/kernel/sys_wildfire.c - 1.3 linux/drivers/usb/serial/keyspan.c - 1.7 linux/drivers/usb/microtek.h - 1.2 linux/drivers/usb/microtek.c - 1.7 linux/drivers/usb/bluetooth.c - 1.8 linux/fs/jffs/inode-v23.c - 1.6 linux/drivers/acpi/interpreter/amstore.c - 1.6 linux/arch/arm/mm/proc-arm720.S - 1.6 linux/arch/i386/kernel/i387.c - 1.6 linux/drivers/acpi/events/evsci.c - 1.5 linux/drivers/acpi/Makefile - 1.6 linux/drivers/ieee1394/guid.c - 1.4 linux/drivers/ieee1394/guid.h - 1.2 linux/include/asm-sparc64/mc146818rtc.h - 1.2 linux/drivers/net/ibmlana.h - 1.2 linux/fs/smbfs/ChangeLog - 1.4 linux/Documentation/cachetlb.txt - 1.6 linux/drivers/sound/cs46xx.c - 1.7 linux/drivers/net/natsemi.c - 1.5 linux/drivers/media/video/zr36120.c - 1.4 linux/drivers/media/video/vino.c - 1.3 linux/drivers/media/video/videodev.c - 1.3 linux/drivers/media/video/stradis.c - 1.4 linux/drivers/media/video/pms.c - 1.4 linux/drivers/media/video/planb.c - 1.4 linux/drivers/media/video/msp3400.c - 1.5 linux/drivers/media/video/cpia_pp.c - 1.2 linux/drivers/media/video/cpia.h - 1.2 linux/drivers/media/video/cpia.c - 1.3 linux/drivers/media/video/c-qcam.c - 1.5 linux/drivers/media/video/bw-qcam.c - 1.5 linux/drivers/media/video/buz.c - 1.5 linux/drivers/media/video/bttv.h - 1.6 linux/drivers/media/video/bttv-driver.c - 1.7 linux/drivers/media/radio/radio-zoltrix.c - 1.5 linux/drivers/media/radio/radio-typhoon.c - 1.5 linux/drivers/media/radio/radio-trust.c - 1.5 linux/drivers/media/radio/radio-terratec.c - 1.5 linux/drivers/media/radio/radio-sf16fmi.c - 1.5 linux/drivers/media/radio/radio-rtrack2.c - 1.5 linux/drivers/media/radio/radio-miropcm20.c - 1.3 linux/drivers/media/radio/radio-gemtek.c - 1.5 linux/drivers/media/radio/radio-cadet.c - 1.4 linux/drivers/media/radio/radio-aztech.c - 1.5 linux/drivers/media/radio/radio-aimslab.c - 1.5 linux/drivers/media/radio/Makefile - 1.4 linux/drivers/media/radio/Config.in - 1.3 linux/drivers/isdn/hysdn/hycapi.c - 1.4 linux/drivers/isdn/hisax/nj_u.c - 1.5 linux/drivers/isdn/hisax/nj_s.c - 1.5 linux/drivers/isdn/hisax/netjet.h - 1.3 linux/drivers/isdn/hisax/l3ni1.h - 1.3 linux/drivers/isdn/hisax/l3ni1.c - 1.4 linux/drivers/isdn/hisax/icc.h - 1.2 linux/drivers/isdn/hisax/icc.c - 1.3 linux/drivers/isdn/eicon/xlog.c - 1.2 linux/drivers/isdn/eicon/uxio.h - 1.2 linux/drivers/isdn/eicon/sys.h - 1.2 linux/drivers/isdn/eicon/pri.c - 1.2 linux/drivers/isdn/eicon/pr_pc.h - 1.2 linux/drivers/isdn/eicon/pc_maint.h - 1.2 linux/drivers/isdn/eicon/pc.h - 1.2 linux/drivers/isdn/eicon/md5sums.asc - 1.3 linux/drivers/isdn/eicon/log.c - 1.2 linux/drivers/isdn/eicon/linsys.c - 1.2 linux/drivers/isdn/eicon/linio.c - 1.3 linux/drivers/isdn/eicon/linchr.c - 1.3 linux/drivers/isdn/eicon/lincfg.c - 1.2 linux/drivers/isdn/eicon/kprintf.c - 1.2 linux/drivers/isdn/eicon/idi.h - 1.3 linux/drivers/isdn/eicon/idi.c - 1.2 linux/drivers/isdn/eicon/fpga.c - 1.2 linux/drivers/isdn/eicon/fourbri.c - 1.2 linux/drivers/isdn/eicon/fcheck.c - 1.2 linux/drivers/isdn/eicon/dspdids.h - 1.2 linux/drivers/isdn/eicon/dsp_defs.h - 1.2 linux/drivers/isdn/eicon/divas.h - 1.2 linux/drivers/isdn/eicon/divalog.h - 1.2 linux/drivers/isdn/eicon/constant.h - 1.2 linux/drivers/isdn/eicon/common.c - 1.3 linux/drivers/isdn/eicon/bri.c - 1.2 linux/drivers/isdn/eicon/adapter.h - 1.2 linux/drivers/isdn/eicon/Divas_mod.c - 1.4 linux/drivers/input/mousedev.c - 1.4 linux/drivers/input/keybdev.c - 1.3 linux/arch/arm/tools/mach-types - 1.3 linux/drivers/md/lvm.c - 1.9 linux/arch/arm/mach-sa1100/arch.c - 1.2 linux/arch/arm/mm/proc-arm920.S - 1.3 linux/drivers/acpi/include/acconfig.h - 1.5 linux/drivers/md/md.c - 1.10 linux/drivers/media/radio/radio-maestro.c - 1.3 linux/drivers/net/hamachi.c - 1.4 linux/drivers/net/sundance.c - 1.4 linux/drivers/net/winbond-840.c - 1.5 linux/drivers/scsi/cpqfcTScontrol.c - 1.3 linux/drivers/scsi/cpqfcTSinit.c - 1.4 linux/drivers/scsi/cpqfcTSworker.c - 1.3 linux/include/asm-arm/hardware/pci_v3.h - 1.2 linux/include/asm-arm/hardware/serial_amba.h - 1.2 linux/include/asm-ppc/highmem.h - 1.3 linux/drivers/ide/slc90e66.c - 1.2 linux/net/core/dv.c - 1.3 linux/drivers/net/tulip/ChangeLog - 1.4 linux/drivers/usb/serial/belkin_sa.c - 1.4 linux/drivers/usb/serial/belkin_sa.h - 1.2 linux/Documentation/dnotify.txt - 1.2 linux/drivers/video/sis/sis_301.h - 1.2 linux/net/irda/irnet/irnet_irda.c - 1.2 linux/net/irda/irnet/irnet.h - 1.2 linux/net/irda/irnet/Config.in - 1.2 linux/include/asm-arm/xor.h - 1.2 linux/include/linux/ethtool.h - 1.2 linux/arch/sparc64/lib/U3copy_in_user.S - 1.2 linux/drivers/parport/parport_gsc.c - 1.4 linux/drivers/usb/serial/mct_u232.c - 1.3 linux/arch/parisc/mm/fault.c - 1.2 linux/drivers/usb/serial/Config.in - 1.3 linux/arch/parisc/kernel/sys_parisc.c - 1.2 linux/drivers/sound/ymfpci.c - 1.4 linux/drivers/acpi/namespace/nsinit.c - 1.4 linux/mm/shmem.c - 1.4 linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.3 linux/arch/m68k/ifpsp060/src/fpsp.S - 1.3 linux/arch/m68k/ifpsp060/src/ilsp.S - 1.2 linux/arch/m68k/ifpsp060/src/isp.S - 1.3 linux/include/asm-ia64/sn/xtalk/xbow.h - 1.2 linux/arch/ia64/sn/io/l1.c - 1.3 linux/arch/ia64/sn/io/pcibr.c - 1.3 linux/include/asm-ia64/sn/sn1/hubmd_next.h - 1.2 linux/include/asm-ia64/sn/sn1/hubmd.h - 1.2 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.2 linux/include/asm-ia64/sn/pci/bridge.h - 1.2 linux/fs/reiserfs/stree.c - 1.2 linux/fs/reiserfs/super.c - 1.2 linux/fs/reiserfs/tail_conversion.c - 1.3 linux/drivers/char/drm/radeon_bufs.c - 1.2 linux/arch/sparc64/kernel/pci_schizo.c - 1.3 linux/fs/reiserfs/ioctl.c - 1.2 linux/fs/reiserfs/inode.c - 1.2 linux/fs/reiserfs/fix_node.c - 1.2 linux/fs/reiserfs/dir.c - 1.2 linux/arch/ppc/kernel/open_pic_defs.h - 1.2 linux/drivers/sbus/char/cpwatchdog.c - 1.2 linux/arch/s390x/kernel/sys_s390.c - 1.2 linux/include/asm-s390x/lowcore.h - 1.2 linux/arch/alpha/kernel/pci-noop.c - 1.2 linux/include/asm-s390x/dasd.h - 1.2 linux/include/asm-s390x/ccwcache.h - 1.2 linux/drivers/sound/maestro3.c - 1.2 linux/arch/s390x/kernel/linux32.c - 1.2 linux/drivers/s390/s390mach.c - 1.2 linux/arch/cris/drivers/serial.c - 1.2 linux/arch/cris/kernel/entry.S - 1.2 linux/arch/cris/kernel/sys_cris.c - 1.2 linux/arch/cris/mm/fault.c - 1.2 linux/drivers/s390/net/netiucv.c - 1.2 linux/arch/s390x/kernel/exec32.c - 1.2 linux/arch/s390x/kernel/entry.S - 1.2 linux/drivers/s390/char/tape34xx.c - 1.2 linux/arch/s390x/kernel/binfmt_elf32.c - 1.2 linux/include/asm-s390x/socket.h - 1.2 linux/arch/s390x/mm/fault.c - 1.2 linux/include/asm-s390/ccwcache.h - 1.2 linux/include/asm-s390x/unistd.h - 1.2 linux/drivers/net/tokenring/tmsisa.c - 1.2 linux/drivers/net/pci-skeleton.c - 1.2 linux/arch/s390x/tools/dasdfmt/dasdfmt.c - 1.2 - 2.4.3 Merge From owner-linux-xfs@oss.sgi.com Mon Apr 2 13:59:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Kxix06444 for linux-xfs-outgoing; Mon, 2 Apr 2001 13:59:44 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32KxhM06441 for ; Mon, 2 Apr 2001 13:59:43 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08767 for ; Mon, 2 Apr 2001 14:09:55 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1330552 for ; Mon, 2 Apr 2001 15:58:27 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA07484 for ; Mon, 2 Apr 2001 15:58:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32KuZo21322; Mon, 2 Apr 2001 15:56:35 -0500 Message-Id: <200104022056.f32KuZo21322@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 15:56:35 -0500 Subject: TAKE - remove yet more kernel intrusions Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It turns out we now have a way around the BH_End_io flag, and can run without it, we can also use fewer special purpose end_io functions and more of the generic cases. Date: Mon Apr 2 13:56:41 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91406a linux/include/linux/fs.h - 1.87 - Remove BH_End_io flag. linux/drivers/block/ll_rw_blk.c - 1.65 - Remove BH_End_io check from ll_rw_block, we do not need it anymore. linux/kdb/modules/kdbm_pg.c - 1.32 - Fixup buffer head flag printing code. linux/fs/pagebuf/page_buf.c - 1.69 - Cleanup buffer flag setting linux/fs/pagebuf/page_buf_io.c - 1.71 - Cleanup end_io handling for buffer heads, we no longer need as many special purpose handlers, or the BH_end_io flag. linux/drivers/md/raid5.c - 1.12 - Remove BH_End_io checks - the flag is gone From owner-linux-xfs@oss.sgi.com Mon Apr 2 14:46:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32Lkbt07828 for linux-xfs-outgoing; Mon, 2 Apr 2001 14:46:37 -0700 Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32LkaM07825 for ; Mon, 2 Apr 2001 14:46:36 -0700 Received: from buytenh by fencepost.gnu.org with local (Exim 3.16 #1 (Debian)) id 14kC9b-0006u6-00; Mon, 02 Apr 2001 17:46:27 -0400 Date: Mon, 2 Apr 2001 17:46:27 -0400 From: Lennert Buytenhek To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.2-XFS stability? (was: Re: O_DIRECT buglet) Message-ID: <20010402174626.A25830@gnu.org> References: <20010401121248.A14579@gnu.org> <3AC75B93.19AB5A8C@thebarn.com> <20010401125601.A15276@gnu.org> <3AC75E89.7AFE485A@thebarn.com> <20010401191059.A6160@gnu.org> <3AC80B4E.796414A8@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AC80B4E.796414A8@thebarn.com>; from cattelan@thebarn.com on Mon, Apr 02, 2001 at 12:17:02AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 02, 2001 at 12:17:02AM -0500, Russell Cattelan wrote: > > Another thing: how stable is 2.4.2-XFS supposed to be? I'm getting dcache- > > related oopses about twice a day on four machines under moderate load > > (typically three rsync's, xfs_fsr), but I have no idea whether this is > > XFS-related or not. > > Well we were thinking more that this suggests. > Somebody else is having trouble with dcache and nfs... it would > seems something is a muck. nfs server, that would be? My disks are exported via nfs, but not mounted by any clients. > Can you give a bit more info as to what you are doing the causes things > to go bad? Nothing special I'd say. Often, just coming here in the morning and seeing my machine wedged. I had no such trouble on 2.2, and these machines never had disk or memory problems. This looks suspicious (happened a few minutes ago). Should I try turning xfs_fsr off? Apr 2 23:00:00 page fsr[2746]: / startino=0 Apr 2 23:00:05 page fsr[2755]: /attic startino=0 Apr 2 23:00:05 page fsr[2756]: /boot startino=0 Apr 2 23:00:05 page fsr[2757]: /data startino=0 Apr 2 23:00:06 page fsr[2760]: /usr startino=0 Apr 2 23:00:55 page kernel: kernel BUG at dcache.c:349! Apr 2 23:00:55 page kernel: invalid operand: 0000 Apr 2 23:00:55 page kernel: CPU: 0 Apr 2 23:00:55 page kernel: EIP: 0010:[prune_dcache+117/332] Apr 2 23:00:55 page kernel: EFLAGS: 00010292 Apr 2 23:00:55 page kernel: eax: 0000001c ebx: c2c070e0 ecx: 00000000 edx: 00000001 Apr 2 23:00:55 page kernel: esi: c2c070c0 edi: c0c11a40 ebp: 0000009f esp: c12e7f98 Apr 2 23:00:55 page kernel: ds: 0018 es: 0018 ss: 0018 Apr 2 23:00:55 page kernel: Process kswapd (pid: 4, stackpage=c12e7000) Apr 2 23:00:55 page kernel: Stack: c02aff41 c02b0001 0000015d 00010f00 00000020 00000004 00000000 c01426b1 Apr 2 23:00:55 page kernel: 000001c2 c012b06b 00000006 00000004 00010f00 c02abdd1 c12e6239 0008e000 Apr 2 23:00:55 page kernel: c012b0fb 00000004 00000000 c12f9fb0 c0105000 00000031 c010752f 00000000 Apr 2 23:00:55 page kernel: Call Trace: [shrink_dcache_memory+33/48] [do_try_to_free_pages+95/124] [kswapd+115/272] [empty_bad_page+0/4096] [kernel_thread+35/48] Apr 2 23:00:56 page kernel: Apr 2 23:00:56 page kernel: Code: 0f 0b 83 c4 0c 8d 46 18 8b 53 f8 8b 48 04 89 4a 04 89 11 89 cheers, Lennert From owner-linux-xfs@oss.sgi.com Mon Apr 2 15:07:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32M73l08811 for linux-xfs-outgoing; Mon, 2 Apr 2001 15:07:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32M72M08808 for ; Mon, 2 Apr 2001 15:07:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA12123 for ; Mon, 2 Apr 2001 15:05:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1346821 for ; Mon, 2 Apr 2001 17:05:45 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA77260 for ; Mon, 2 Apr 2001 17:05:45 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f32M3qm26517; Mon, 2 Apr 2001 17:03:52 -0500 Message-Id: <200104022203.f32M3qm26517@jen.americas.sgi.com> Date: Mon, 2 Apr 2001 17:03:52 -0500 Subject: TAKE - backout part of previous fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I forgot about the buffer list implication of calling buffer_IO_error. Date: Mon Apr 2 15:04:57 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91413a linux/fs/pagebuf/page_buf.c - 1.70 - Back out the use of buffer_IO_error, it gets our buffers onto lists we do not want them on. From owner-linux-xfs@oss.sgi.com Mon Apr 2 15:09:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32M9Bx08891 for linux-xfs-outgoing; Mon, 2 Apr 2001 15:09:11 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32M9BM08888 for ; Mon, 2 Apr 2001 15:09:11 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA12494 for ; Mon, 2 Apr 2001 15:07:56 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1345889; Mon, 2 Apr 2001 17:07:53 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA57159; Mon, 2 Apr 2001 17:07:53 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f32M61826548; Mon, 2 Apr 2001 17:06:01 -0500 Message-Id: <200104022206.f32M61826548@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Lennert Buytenhek cc: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: 2.4.2-XFS stability? (was: Re: O_DIRECT buglet) In-Reply-To: Message from Lennert Buytenhek of "Mon, 02 Apr 2001 17:46:27 EDT." <20010402174626.A25830@gnu.org> Date: Mon, 02 Apr 2001 17:06:00 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmm, fsr does funky stuff, it could be the culprit here. It uses a special call to flip the entent info between two inodes, maybe it has a reference count problem. Steve > This looks suspicious (happened a few minutes ago). Should I try turning > xfs_fsr off? > > Apr 2 23:00:00 page fsr[2746]: / startino=0 > Apr 2 23:00:05 page fsr[2755]: /attic startino=0 > Apr 2 23:00:05 page fsr[2756]: /boot startino=0 > Apr 2 23:00:05 page fsr[2757]: /data startino=0 > Apr 2 23:00:06 page fsr[2760]: /usr startino=0 > Apr 2 23:00:55 page kernel: kernel BUG at dcache.c:349! > Apr 2 23:00:55 page kernel: invalid operand: 0000 > Apr 2 23:00:55 page kernel: CPU: 0 > Apr 2 23:00:55 page kernel: EIP: 0010:[prune_dcache+117/332] > Apr 2 23:00:55 page kernel: EFLAGS: 00010292 > Apr 2 23:00:55 page kernel: eax: 0000001c ebx: c2c070e0 ecx: 00000000 > edx: 00000001 > Apr 2 23:00:55 page kernel: esi: c2c070c0 edi: c0c11a40 ebp: 0000009f > esp: c12e7f98 > Apr 2 23:00:55 page kernel: ds: 0018 es: 0018 ss: 0018 > Apr 2 23:00:55 page kernel: Process kswapd (pid: 4, stackpage=c12e7000) > Apr 2 23:00:55 page kernel: Stack: c02aff41 c02b0001 0000015d 00010f00 00000 > 020 00000004 00000000 c01426b1 > Apr 2 23:00:55 page kernel: 000001c2 c012b06b 00000006 00000004 00010 > f00 c02abdd1 c12e6239 0008e000 > Apr 2 23:00:55 page kernel: c012b0fb 00000004 00000000 c12f9fb0 c0105 > 000 00000031 c010752f 00000000 > Apr 2 23:00:55 page kernel: Call Trace: [shrink_dcache_memory+33/48] [do_try > _to_free_pages+95/124] [kswapd+115/272] [empty_bad_page+0/4096] [kernel_threa > d+35/48] > Apr 2 23:00:56 page kernel: > Apr 2 23:00:56 page kernel: Code: 0f 0b 83 c4 0c 8d 46 18 8b 53 f8 8b 48 04 > 89 4a 04 89 11 89 > > > > cheers, > Lennert From owner-linux-xfs@oss.sgi.com Mon Apr 2 19:37:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f332brq16643 for linux-xfs-outgoing; Mon, 2 Apr 2001 19:37:53 -0700 Received: from flowers.house.larsshack.org (lars@h00059aa0e40d.ne.mediaone.net [66.31.89.164]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f332bmM16637 for ; Mon, 2 Apr 2001 19:37:52 -0700 Received: from localhost (lars@localhost) by flowers.house.larsshack.org (8.11.0/8.11.0) with ESMTP id f332bb101511 for ; Mon, 2 Apr 2001 22:37:38 -0400 X-Authentication-Warning: flowers.house.larsshack.org: lars owned process doing -bs Date: Mon, 2 Apr 2001 22:37:37 -0400 (EDT) From: Lars Kellogg-Stedman X-Sender: To: Subject: Re: XFS 2.4.3 patch In-Reply-To: <3AC79810.ED6F7061@thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just a caveat to other folks on the list: I have a dual bus Adaptec controller on my motherboard. I've got the controller configured to probe bus "B" first, and bus "A" second (bus "A" is the narrow bus). Under 2.4.2, this meant that bus "B" was scsi0. The Adaptec driver in 2.4.3 doesn't appear to care about this particular setting, so bus "A" is now scsi0. The net result is that anything specified by device (/dev/sd/c0b0t10u0) had to be renumbered. Not a biggy, but something to watch out for if you're about to dive head first into a freshly built 2.4.3+XFS kernel. This was covered in far more detail, I believe, on linux-kernel, but that was a week or so ago. -- Lars -- Lars Kellogg-Stedman From owner-linux-xfs@oss.sgi.com Mon Apr 2 20:13:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f333DI317856 for linux-xfs-outgoing; Mon, 2 Apr 2001 20:13:18 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f333DHM17850 for ; Mon, 2 Apr 2001 20:13:17 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA10818 for ; Mon, 2 Apr 2001 20:12:01 -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 NAA39582 for linux-xfs@oss.sgi.com; Tue, 3 Apr 2001 13:11:39 +1000 (EST) Date: Tue, 3 Apr 2001 13:11:39 +1000 (EST) From: Nathan Scott Message-Id: <200104030311.NAA39582@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - group quota support Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This mod converts us from the IRIX project quota implementation over to a Linux group quota "equivalent". It is not possible to mount an IRIX filesystem with project quota enabled (quotaoff can be used to disable quota) - never was under Linux, actually - now that restriction is enforced. For folks using quota under Linux XFS (user/group/both), you must now use the 3.01 quota tools available at: http://sourceforge.net/projects/linuxquota/ cheers. Date: Mon Apr 2 19:52:38 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/nathans/quota-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91436a linux/fs/xfs/xfs_trans_dquot.c - 1.31 linux/fs/xfs/xfsidbg.c - 1.157 linux/fs/xfs/xfs_quota_priv.h - 1.17 linux/fs/xfs/xfs_buf_item.h - 1.33 linux/fs/xfs/xfs_sb.h - 1.50 linux/fs/xfs/xfs_vnodeops.c - 1.493 linux/fs/xfs/xfsquotasstubs.c - 1.13 linux/fs/xfs/xfs_dqblk.h - 1.6 linux/fs/xfs/xfs_itable.c - 1.97 linux/fs/xfs/xfs_qm_syscalls.c - 1.51 linux/fs/xfs/xfs_log_recover.c - 1.204 linux/fs/xfs/xfs_dquot_item.h - 1.6 linux/fs/xfs/xfs_dquot_item.c - 1.22 linux/fs/xfs/xfs_vfsops.c - 1.311 linux/fs/xfs/xfs_iget.c - 1.134 linux/fs/xfs/xfs_clnt.h - 1.22 linux/fs/xfs/xfs_bmap_btree.c - 1.117 linux/fs/xfs/xfs_dquot.h - 1.18 linux/fs/xfs/xfs_dquot.c - 1.55 linux/fs/xfs/xfs_mount.c - 1.249 linux/fs/xfs/xfs_qm.h - 1.18 linux/fs/xfs/xfs_qm.c - 1.63 linux/fs/xfs/xfs_inode.c - 1.312 linux/fs/xfs/xfs_inode.h - 1.145 linux/fs/xfs/xfs_utils.c - 1.36 linux/fs/xfs/xfs_bmap.c - 1.265 linux/fs/xfs/xfs_quota.h - 1.23 linux/fs/xfs/xfs_trans_buf.c - 1.92 linux/fs/xfs/linux/xfs_lrw.c - 1.86 linux/fs/xfs/linux/xfs_super.c - 1.112 linux/include/linux/xqm.h - 1.5 cmd/xfsprogs/repair/xfs_repair.c - 1.2 cmd/xfsprogs/repair/versions.c - 1.2 cmd/xfsprogs/repair/sb.c - 1.2 cmd/xfsprogs/repair/phase6.c - 1.2 cmd/xfsprogs/repair/phase4.c - 1.2 cmd/xfsprogs/db/sb.c - 1.2 cmd/xfsprogs/db/inode.c - 1.2 cmd/xfsprogs/db/frag.c - 1.2 cmd/xfsprogs/repair/globals.h - 1.2 cmd/xfsprogs/repair/dir2.c - 1.2 cmd/xfsprogs/repair/dir.c - 1.2 cmd/xfsprogs/repair/dinode.c - 1.2 cmd/xfsprogs/repair/agheader.c - 1.2 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.7 cmd/xfsprogs/logprint/log_print_all.c - 1.2 cmd/xfsprogs/libxfs/xfs_mount.c - 1.2 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.2 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.2 cmd/xfsprogs/include/xqm.h - 1.3 cmd/xfsprogs/include/xfs_sb.h - 1.2 cmd/xfsprogs/db/dquot.c - 1.2 cmd/xfsprogs/include/xfs_quota.h - 1.2 cmd/xfsprogs/include/xfs_inode.h - 1.4 cmd/xfsprogs/include/xfs_dquot_item.h - 1.2 cmd/xfsprogs/include/xfs_dqblk.h - 1.2 cmd/xfsprogs/include/xfs_buf_item.h - 1.2 cmd/xfsprogs/db/check.c - 1.2 cmd/xfsprogs/doc/README.quota - 1.3 - support group quota in Linux/XFS. cmd/xfsprogs/VERSION - 1.11 cmd/xfsprogs/doc/CHANGES - 1.12 cmd/xfsprogs/debian/changelog - 1.7 linux/Documentation/Changes - 1.36 - move to version 1.2.0 for group quota changes. From owner-linux-xfs@oss.sgi.com Mon Apr 2 21:01:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3341nZ19236 for linux-xfs-outgoing; Mon, 2 Apr 2001 21:01:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3341mM19233 for ; Mon, 2 Apr 2001 21:01:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08919 for ; Mon, 2 Apr 2001 21:11:59 -0700 (PDT) mail_from (ivanr@snort.melbourne.sgi.com) Received: (from ivanr@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA12439; Tue, 3 Apr 2001 13:58:42 +1000 (EST) Date: Tue, 3 Apr 2001 13:58:42 +1000 (EST) From: Ivan Rayner Message-Id: <200104030358.NAA12439@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ivanr@snort.melbourne.sgi.com Subject: TAKE - add quota support to xfsdump Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 20:57:58 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build6/ivanr/isms/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:91438a cmd/xfsdump/dump/content.c - 1.3 cmd/xfsdump/common/util.c - 1.2 cmd/xfsdump/common/content.h - 1.2 cmd/xfsdump/restore/content.c - 1.4 - add quota support From owner-linux-xfs@oss.sgi.com Mon Apr 2 21:06:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3346os19372 for linux-xfs-outgoing; Mon, 2 Apr 2001 21:06:50 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3346nM19369 for ; Mon, 2 Apr 2001 21:06:49 -0700 Received: from snort.melbourne.sgi.com ([134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA03140 for ; Mon, 2 Apr 2001 21:06:46 -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 OAA32210 for linux-xfs@oss.sgi.com; Tue, 3 Apr 2001 14:05:10 +1000 (EST) Date: Tue, 3 Apr 2001 14:05:10 +1000 (EST) From: Nathan Scott Message-Id: <200104030405.OAA32210@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump version Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 21:04:55 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91439a cmd/xfsdump/VERSION - 1.5 cmd/xfsdump/doc/CHANGES - 1.5 - bump to 1.0.4 for Ivans quota changes. From owner-linux-xfs@oss.sgi.com Mon Apr 2 23:29:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f336TrL22930 for linux-xfs-outgoing; Mon, 2 Apr 2001 23:29:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f336TqM22927 for ; Mon, 2 Apr 2001 23:29:52 -0700 Received: from waco.engr.sgi.com ([163.154.18.95]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA01593 for ; Mon, 2 Apr 2001 23:29:51 -0700 (PDT) mail_from (ananth@waco.engr.sgi.com) Received: (from ananth@localhost) by waco.engr.sgi.com (8.11.2/8.11.2) id f336UMv28071 for linux-xfs@oss.sgi.com; Mon, 2 Apr 2001 23:30:22 -0700 Date: Mon, 2 Apr 2001 23:30:22 -0700 From: Ananth Ananthanarayanan Message-Id: <200104030630.f336UMv28071@waco.engr.sgi.com> Subject: TAKE - code cleaup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 2 23:27:25 PDT 2001 Workarea: waco.engr.sgi.com:/build1/ananth/xfs-tot The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91443a linux/fs/pagebuf/page_buf_io.c - 1.72 - Avoid an extra function in writepage path, use pagebuf_delalloc_convert directly. Other misc. cleanups. From owner-linux-xfs@oss.sgi.com Tue Apr 3 00:49:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f337nha24993 for linux-xfs-outgoing; Tue, 3 Apr 2001 00:49:43 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f337naM24990 for ; Tue, 3 Apr 2001 00:49:36 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA29659 for ; Tue, 3 Apr 2001 00:48:20 -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 RAA95890; Tue, 3 Apr 2001 17:47:55 +1000 (EST) Date: Tue, 3 Apr 2001 17:47:55 +1000 From: Timothy Shimmin To: John Trostel Cc: Carlos Gamboa Dos Santos , linux-xfs@oss.sgi.com, Andrew Gildfind Subject: Re: Problems with ACL inheritance and chacl & maybe a BUG Message-ID: <20010403174755.G96384@boing.melbourne.sgi.com> References: <3AC35789.FF9BBCA@iee.lu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from jtrostel@connex.com on Thu, Mar 29, 2001 at 05:29:32PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After looking at the Revised section 5 in the withdrawn ACL standard, 5.3.1.2 states how a newly created file will obtain its ACLs. And indeed, if the ACLs are turned on and a file is created in a directory which has a default ACL, then the umask is not supposed to be used at all - only the default ACL and the operation's mode are to be used. The rational for this is given in section B.23.5 where it actually explicitly says that the umask is not to be used. Looking at the code in fs/xfs/xfs_acl.c and xfs_acl_inherit() it is doing the right thing. However, by this stage of setting up the acl the vap->va_mode has already been changed by the umask ! So there is our bug. In fs/namei.c (vfs_create(), vfs_mknod() and vfs_mkdir()) it updates the mode with the umask (before we get to see the mode argument). There needs to be a test on the directory to see if it has a default ACL before updating the mode with the umask. Looking at Andreas' ACL patch, he has in fact patched fs/namei.c for each case of where umask is used. If the inode's fs has ACLs turned on (inode)->i_sb->s_ext_attr_flags & EXT_ATTR_FLAG_POSIX_ACL then he doesn't use the umask. Then in the ACL code, he uses the umask if the directory doesn't have a default ACL. I'll have a look at ways to fix our code tomorrow. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Tue Apr 3 09:24:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33GOkO07750 for linux-xfs-outgoing; Tue, 3 Apr 2001 09:24:46 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33GOkM07747 for ; Tue, 3 Apr 2001 09:24:46 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA17040 for ; Tue, 3 Apr 2001 09:23:30 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1271423 for ; Tue, 3 Apr 2001 11:23:29 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA97690 for ; Tue, 3 Apr 2001 11:23:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f33GLC106975; Tue, 3 Apr 2001 11:21:12 -0500 Message-Id: <200104031621.f33GLC106975@jen.americas.sgi.com> Date: Tue, 3 Apr 2001 11:21:12 -0500 Subject: TAKE - yet more pagebuf code rationalization Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some more code removal - left behind from previous simplifications, remove some locking from the read path. Date: Tue Apr 3 09:22:18 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91469a linux/fs/xfs/linux/xfs_lrw.c - 1.87 - Less locking in the read path, cleanup lock mode calculation in the write path and remove the PBMF_NEW flag. linux/include/linux/page_buf.h - 1.84 - Remove some dead definitions. linux/fs/pagebuf/page_buf.c - 1.71 - Simplify some more code, removing dead paths and unused calculations left over from previous versions of the code. linux/fs/pagebuf/page_buf_io.c - 1.73 - Remove some dead code, optimize out the prepare_write call when the page is already upto date, deal with EAGAIN coming back from the strategy call. From owner-linux-xfs@oss.sgi.com Tue Apr 3 09:44:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33GifP08619 for linux-xfs-outgoing; Tue, 3 Apr 2001 09:44:41 -0700 Received: from hotmail.com (f196.law11.hotmail.com [64.4.17.196]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33GifM08616 for ; Tue, 3 Apr 2001 09:44:41 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Apr 2001 09:44:36 -0700 Received: from 205.227.43.15 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 03 Apr 2001 16:44:36 GMT X-Originating-IP: [205.227.43.15] From: "B. Dawkins" To: linux-xfs@oss.sgi.com Subject: Oracle database running on XFS? Date: Tue, 03 Apr 2001 09:44:36 -0700 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 03 Apr 2001 16:44:36.0298 (UTC) FILETIME=[5E17EAA0:01C0BC5D] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk
Does the Oracle Database run on SGI XFS?
 
Thanks,
Brandy

Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-linux-xfs@oss.sgi.com Tue Apr 3 10:11:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33HBZH09695 for linux-xfs-outgoing; Tue, 3 Apr 2001 10:11:35 -0700 Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33HBYM09692 for ; Tue, 3 Apr 2001 10:11:34 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id TAA23017; Tue, 3 Apr 2001 19:11:12 +0200 Received: from localhost (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.11.2/8.9.3) with ESMTP id f33HBCG02639; Tue, 3 Apr 2001 19:11:12 +0200 Date: Tue, 3 Apr 2001 19:11:12 +0200 (CEST) From: Adam Cioccarelli To: "B. Dawkins" cc: Subject: Re: Oracle database running on XFS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I can't speak for a production database but I have had a heavily used development database running for about a month now (and a less heavily used one for about three months). No problems at all so far. ------------------------------------------------------------------------------- Adam Cioccarelli (B.E Mechanical) Adam.Cioccarelli@ecetra.com Database Administrator Phone: +43 1 536 89 7725 Fax: +43 1 536 89 7719 ecetra Central European e-Finance AG Mobile:+43 664 181 4195 ------------------------------------------------------------------------------- On Tue, 3 Apr 2001, B. Dawkins wrote: > Does the Oracle Database run on SGI XFS? >   > Thanks, > Brandy > > ________________________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > From owner-linux-xfs@oss.sgi.com Tue Apr 3 10:32:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33HW4t10850 for linux-xfs-outgoing; Tue, 3 Apr 2001 10:32:04 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33HW3M10847 for ; Tue, 3 Apr 2001 10:32:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02323 for ; Tue, 3 Apr 2001 10:42:12 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1347601; Tue, 3 Apr 2001 12:29:34 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA11853; Tue, 3 Apr 2001 12:29:34 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f33HRG609656; Tue, 3 Apr 2001 12:27:16 -0500 Message-Id: <200104031727.f33HRG609656@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Adam Cioccarelli cc: "B. Dawkins" , linux-xfs@oss.sgi.com Subject: Re: Oracle database running on XFS? In-Reply-To: Message from Adam Cioccarelli of "Tue, 03 Apr 2001 19:11:12 +0200." Content-Transfer-Encoding: 8bit Date: Tue, 03 Apr 2001 12:27:16 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adam Cioccarelli wrote: > I can't speak for a production database but I have had a > heavily used development database running for about a month now (and a > less heavily used one for about three months). No problems at all so far. > > > On Tue, 3 Apr 2001, B. Dawkins wrote: > > > Does the Oracle Database run on SGI XFS? And Oracle said they might go and checkout xfs on linux themselves since it has direct I/O which they would like to use. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 3 10:32:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33HWIw10862 for linux-xfs-outgoing; Tue, 3 Apr 2001 10:32:18 -0700 Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33HWDM10857 for ; Tue, 3 Apr 2001 10:32:13 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id NAA28574; Tue, 3 Apr 2001 13:32:06 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 3 Apr 2001 13:32:06 -0400 (EDT) From: Joshua Baker-LePain X-Sender: Reply-To: Linux xfs mailing list To: Lars Kellogg-Stedman cc: Linux xfs mailing list Subject: Re: XFS 2.4.3 patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2 Apr 2001 at 10:37pm, Lars Kellogg-Stedman wrote > I have a dual bus Adaptec controller on my motherboard. I've got the > controller configured to probe bus "B" first, and bus "A" second (bus "A" > is the narrow bus). > > Under 2.4.2, this meant that bus "B" was scsi0. > > The Adaptec driver in 2.4.3 doesn't appear to care about this particular > setting, so bus "A" is now scsi0. The net result is that anything > specified by device (/dev/sd/c0b0t10u0) had to be renumbered. > > Not a biggy, but something to watch out for if you're about to dive > head first into a freshly built 2.4.3+XFS kernel. This was covered in > far more detail, I believe, on linux-kernel, but that was a week or so > ago. > To contine in this vein, the recommended fix seemed to be to download the latest driver (6.1.8) from . I've got that running now (also on a machine with an embedded, dual channel controller), on a kernel pulled out of CVS this morning and everything was detected as expected. Now we'll see how 3c59x and nfsd hold up. Sooner or later, I will have to let the grad students at this RAID array. *sigh* -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Apr 3 10:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33HZ3Q11011 for linux-xfs-outgoing; Tue, 3 Apr 2001 10:35:03 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33HZ3M11008 for ; Tue, 3 Apr 2001 10:35:03 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA06876 for ; Tue, 3 Apr 2001 10:45:15 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1287359 for ; Tue, 3 Apr 2001 12:33:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA02741 for ; Tue, 3 Apr 2001 12:33:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f33HVS509775; Tue, 3 Apr 2001 12:31:28 -0500 Message-Id: <200104031731.f33HVS509775@jen.americas.sgi.com> Date: Tue, 3 Apr 2001 12:31:28 -0500 Subject: TAKE - get a few function calls out of the hot paths Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kernel profiling was showing these paths up as hot spots, there was some overhead we could get rid of here. Date: Tue Apr 3 10:32:55 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91474a linux/fs/xfs/xfs_btree.c - 1.88 linux/fs/xfs/xfs_btree.h - 1.51 linux/fs/xfs/linux/xfs_iops.c - 1.98 linux/fs/xfs/linux/xfs_ioctl.c - 1.33 - Avoid a function call based on kernel profiling showing it up From owner-linux-xfs@oss.sgi.com Tue Apr 3 13:01:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33K1rY16674 for linux-xfs-outgoing; Tue, 3 Apr 2001 13:01:53 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33K1qM16671 for ; Tue, 3 Apr 2001 13:01:52 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA6775847 for ; Tue, 3 Apr 2001 22:01:49 +0200 (CEST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1345694 for ; Tue, 3 Apr 2001 15:00:27 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA85820 for ; Tue, 3 Apr 2001 15:00:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f33Jw8H24799; Tue, 3 Apr 2001 14:58:08 -0500 Message-Id: <200104031958.f33Jw8H24799@jen.americas.sgi.com> Date: Tue, 3 Apr 2001 14:58:08 -0500 Subject: TAKE - expand xfsstats script to do pagebuf stats Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 3 13:00:08 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91509a cmd/xfsmisc/xfs_stats.pl - 1.2 - Add pagebuf stats to output From owner-linux-xfs@oss.sgi.com Tue Apr 3 15:53:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33Mr1x22375 for linux-xfs-outgoing; Tue, 3 Apr 2001 15:53:01 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33Mr0M22372 for ; Tue, 3 Apr 2001 15:53:00 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA06286 for ; Tue, 3 Apr 2001 15:53:00 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA39827; Tue, 3 Apr 2001 17:51:44 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f33Me9b14034; Tue, 3 Apr 2001 18:40:09 -0400 Message-ID: <3ACA5148.FC61A9A3@thebarn.com> Date: Tue, 03 Apr 2001 18:40:09 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Shekhawat CC: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch References: <3AC6733F.3B62AC5E@thebarn.com> <20010401145556.U16131@zaurak.cedar.buffalo.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ajay Shekhawat wrote: > On Sat, Mar 31, 2001 at 06:15:59PM -0600, Russell Cattelan wrote: > > A preliminary XFS patch for 2.4.3 has been placed on > > oss.sgi.com/linux-xfs.sgi.com > > ftp://linux-xfs.sgi.com/projects/xfs/download/patches/ > > > > This has passed basic bonnie and dbench runs, but has > > not been extensivly tested, but due to the limited number > > of changes things should work just fine. > > > > The CVS tree will be updated in the next few days. > > > > -Russell > We haven't been able to duplicate this panic locally yet. Could you let us know what you are using for test machines client and server, number of processors in each, kernel version, linux distro version, speed of network between the machines. Finally what are you doing to "stress" nfs? > > I built the 2.4.3-XFS kernel on our test machine, and tried hammering on > the machine via NFS. Unfortunately, after about 10 hours or so of work, > I get an "oops". The messages are attached below. It _appears_ that the > machine is running out of some resource. The second 'oops' below occured > when I tried to rlogin into the machine; it is caused by "tcsh" ! > > Any help in tracking this down would be appreciated. > > Ajay > > ------------------------------------------------------------------------ > > ksymoops.txt.20Name: ksymoops.txt.20 > Type: Plain Text (text/plain) > > ksymoops.txt.33Name: ksymoops.txt.33 > Type: Plain Text (text/plain) -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Apr 3 16:01:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33N1nN22624 for linux-xfs-outgoing; Tue, 3 Apr 2001 16:01:49 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33N1dM22621 for ; Tue, 3 Apr 2001 16:01:39 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA09992 for ; Tue, 3 Apr 2001 16:01:23 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA13636; Tue, 3 Apr 2001 17:59:14 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f33Mldb14063; Tue, 3 Apr 2001 18:47:39 -0400 Message-ID: <3ACA530B.E9ECD29D@thebarn.com> Date: Tue, 03 Apr 2001 18:47:39 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Utz Lehmann CC: linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs References: <20010329165519.A7386@tecosim.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Utz Lehmann wrote: > Hi > > With newer cvs kernel (cvs from this week, before i had holidays) i have > problems with my linux workstation (suse 7.1) at work. > > Umounting the filesystems while shutdown hangs. > > Following partitions are xfs: > > /dev/sda1 on / type xfs (rw) > /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) > /dev/vg00/var on /var type xfs (rw,kio,logbufs=4,logbsize=32768) > /dev/vg00/opt on /opt type xfs (rw,kio,logbufs=4,logbsize=32768) > /dev/vg00/tmp on /tmp type xfs (rw,kio,logbufs=4,logbsize=32768) I assume these are lvm volumes? Could you sent configuration of these volumes. Also one more kdb command. kdb> bta Back trace all. We need to find out why the pagebuf pagebuf_delwri_flush is currently working on has a pin count.... that shouldn't be happening at this point. > > After umounting /tmp and /opt it hangs. Normally /var and /usr followed. > > It hangs in the /etc/init.d/halt script: > > [...] > echo "Unmounting file systems" > umount -avt noproc,nonfs,nosmbfs || { > rc_status > UMOUNT_FAILED=true > } > rc_status -v1 -r > > With a cvs kernel from march 2nd i have no problems. > > regards. > > utz lehmann -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Tue Apr 3 16:06:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33N63Y22690 for linux-xfs-outgoing; Tue, 3 Apr 2001 16:06:03 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33N62M22687 for ; Tue, 3 Apr 2001 16:06:02 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA16993 for ; Tue, 3 Apr 2001 16:04:47 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1360592 for ; Tue, 3 Apr 2001 18:04:46 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA24796 for ; Tue, 3 Apr 2001 18:04:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f33N2P503119; Tue, 3 Apr 2001 18:02:25 -0500 Message-Id: <200104032302.f33N2P503119@jen.americas.sgi.com> Date: Tue, 3 Apr 2001 18:02:25 -0500 Subject: TAKE - check kiobuf I/O path in as a patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are removing the kiobuf based I/O path from the xfs development tree. This is being done due to the direction being taken in the Linux community with block layer changes, at the moment support for getting this code into other kernels is non-existent. Other approaches to large size I/O requests are being worked on, once one emerges, support for it will be added to XFS. Date: Tue Apr 3 16:02:04 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91557a cmd/xfsmisc/kiobuf_io.patch - 1.1 - The kiobuf I/O patch - apply this to get the kiobuf I/O path back into the kernel. cmd/xfsmisc/README - 1.2 - Added info on kiobuf_io.patch From owner-linux-xfs@oss.sgi.com Tue Apr 3 16:10:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33NA7J22736 for linux-xfs-outgoing; Tue, 3 Apr 2001 16:10:07 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33NA7M22733 for ; Tue, 3 Apr 2001 16:10:07 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA17443 for ; Tue, 3 Apr 2001 16:08:51 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1358715 for ; Tue, 3 Apr 2001 18:08:50 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA49787 for ; Tue, 3 Apr 2001 18:08:50 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f33N6TC03201; Tue, 3 Apr 2001 18:06:29 -0500 Message-Id: <200104032306.f33N6TC03201@jen.americas.sgi.com> Date: Tue, 3 Apr 2001 18:06:29 -0500 Subject: TAKE - remove kiobuf based I/O path Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are removing the kiobuf based I/O path from the xfs development tree. This is being done due to the direction being taken in the Linux community with block layer changes, at the moment support for getting this code into other kernels is non-existent. Other approaches to large size I/O requests are being worked on, once one emerges, support for it will be added to XFS. The code has been checked in to cmd/xfsmisc/kiobuf_io.patch to allow people who want to to reapply the patch. Date: Tue Apr 3 16:07:43 PDT 2001 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91559a linux/kernel/ksyms.c - 1.83 linux/include/linux/major.h - 1.25 linux/include/linux/genhd.h - 1.12 linux/include/linux/fs.h - 1.88 linux/include/linux/blkdev.h - 1.30 linux/fs/buffer.c - 1.60 linux/drivers/scsi/sd.c - 1.34 linux/drivers/block/rd.c - 1.28 linux/drivers/block/loop.c - 1.30 linux/drivers/block/ll_rw_blk.c - 1.66 linux/include/linux/ide.h - 1.28 linux/fs/iobuf.c - 1.17 linux/drivers/char/raw.c - 1.14 linux/include/linux/iobuf.h - 1.11 linux/fs/partitions/check.c - 1.22 linux/drivers/scsi/scsi_merge.c - 1.27 linux/drivers/scsi/scsi_lib.c - 1.29 linux/drivers/ide/ide.c - 1.20 linux/drivers/ide/ide-dma.c - 1.10 linux/drivers/ide/ide-disk.c - 1.13 linux/drivers/block/elevator.c - 1.8 linux/fs/xfs/linux/xfs_super.c - 1.113 linux/kdb/modules/kdbm_pg.c - 1.33 linux/fs/pagebuf/page_buf.c - 1.72 linux/drivers/md/raid1.c - 1.7 linux/drivers/md/raid5.c - 1.13 From owner-linux-xfs@oss.sgi.com Tue Apr 3 16:43:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33Nh9823692 for linux-xfs-outgoing; Tue, 3 Apr 2001 16:43:09 -0700 Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33Nh7M23689 for ; Tue, 3 Apr 2001 16:43:08 -0700 Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net) by tux.mkp.net with esmtp (Exim 3.16 #1) id 14kaRe-0004bN-00; Wed, 04 Apr 2001 01:42:56 +0200 Received: (from mkp@localhost) by jaguar.mkp.net (8.9.3/8.9.3) id TAA00776; Tue, 3 Apr 2001 19:42:00 -0400 X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f To: Russell Cattelan Cc: Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs References: <20010329165519.A7386@tecosim.de> <3ACA530B.E9ECD29D@thebarn.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 03 Apr 2001 19:41:59 -0400 In-Reply-To: <3ACA530B.E9ECD29D@thebarn.com> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Urania) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Russell" == Russell Cattelan writes: >> /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) ^^^ I just noticed this - we don't support kio with LVM. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Tue Apr 3 16:56:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33NuWd24013 for linux-xfs-outgoing; Tue, 3 Apr 2001 16:56:32 -0700 Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f33NuVM24010 for ; Tue, 3 Apr 2001 16:56:31 -0700 Received: (qmail 15523 invoked from network); 3 Apr 2001 23:56:30 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 3 Apr 2001 23:56:30 -0000 Received: (from ajay@localhost) by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id TAA25471; Tue, 3 Apr 2001 19:56:30 -0400 (EDT) Date: Tue, 3 Apr 2001 19:56:30 -0400 From: Ajay Shekhawat To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch Message-ID: <20010403195629.T16131@zaurak.cedar.buffalo.edu> References: <3AC6733F.3B62AC5E@thebarn.com> <20010401145556.U16131@zaurak.cedar.buffalo.edu> <3ACA5148.FC61A9A3@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACA5148.FC61A9A3@thebarn.com>; from cattelan@thebarn.com on Tue, Apr 03, 2001 at 06:40:09PM -0400 Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 03, 2001 at 06:40:09PM -0400, Russell Cattelan wrote: > We haven't been able to duplicate this panic locally yet. > Could you let us know what you are using for test machines > client and server, number of processors in each, kernel version, > linux distro version, speed of network between the machines. > Finally what are you doing to "stress" nfs? The server is a dual P-II 450MHz machine with an ASUS P2B-DS motherboard and 256MB memory. It has a 3c905B ethernet card, leading to a Cisco Cat 5000 switch. This machine is running RedHat Wolverine, with the kernel upgraded to 2.4.3-XFS (i.e., stock 2.4.3 with the XFS patches). It has an onboard AIC7890 SCSI controller. It has 3 Seagate ST34502LW 4GB SCSI disks. One of these disks has been formatted as XFS, and is exported via NFS. The server has NFSv3 support enabled, and kernel NFSD. The clients are 4 Linux boxes, each running RH6.2 or RH7.0. All have 100bT ethernet hooked to the Cat 5000. All of the clients mount the exported filesystem from the server. This filesystem contains 1000 files of 3MB each. There is a "file list" at the top level, which contains a list of all the files including the full pathname. Each of the clients runs a Perl script in a tight loop which does the following: - Grabs a random filename from this list - stat()s and opens that file, and reads the entire contents - close()s the file One of the clients (a dual P-III 800MHz box) has a script that also continuously writes files of size [4K .. 1MB]; it keeps at most 32 files around, deleting old ones as it creates new ones. This test setup looks weird, but it is designed to sort of simulate the end use that this server is likely to get. After about 18 hours or so of usage, the machine gets an oops. In this time, the clients have each read about 38000 files each. Ajay From owner-linux-xfs@oss.sgi.com Tue Apr 3 18:02:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3412ln25976 for linux-xfs-outgoing; Tue, 3 Apr 2001 18:02:47 -0700 Received: from femail1.rdc1.on.home.com (femail1.rdc1.on.home.com [24.2.9.88]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3412kM25972 for ; Tue, 3 Apr 2001 18:02:46 -0700 Received: from coredp.com ([24.66.30.110]) by femail1.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010404010108.FSQD17084.femail1.rdc1.on.home.com@coredp.com> for ; Tue, 3 Apr 2001 18:01:08 -0700 Message-ID: <3ACA72EC.DF052698@coredp.com> Date: Tue, 03 Apr 2001 21:03:40 -0400 From: Andrew Ho X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en, zh, zh-CN, zh-TW MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: jdm.h is missing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I compile linux-2.4-xfs/cmd/xfsdump/. The error messages are as follows: attr.c: In function `jdm_attr_list': attr.c:179: `jdm_filehandle_t' undeclared (first use in this function) attr.c:179: `filehandle' undeclared (first use in this function) attr.c:179: warning: statement with no effect attr.c:180: parse error before `hlen' attr.c:183: `hlen' undeclared (first use in this function) attr.c:184: `rval' undeclared (first use in this function) attr.c:187: warning: control reaches end of non-void function make[1]: *** [attr.o] Error 1 I check the "attr.h". /* attr.h */ #ifndef ATTR_H #define ATTR_H #include #include /* */ From owner-linux-xfs@oss.sgi.com Tue Apr 3 18:13:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f341Dkn26094 for linux-xfs-outgoing; Tue, 3 Apr 2001 18:13:46 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f341DiM26091 for ; Tue, 3 Apr 2001 18:13:45 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA6858138 for ; Wed, 4 Apr 2001 03:13:42 +0200 (CEST) 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 LAA27223; Wed, 4 Apr 2001 11:12:05 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA20864; Wed, 4 Apr 2001 11:12:00 +1000 (EST) From: "Nathan Scott" Message-Id: <10104041111.ZM20875@wobbly.melbourne.sgi.com> Date: Wed, 4 Apr 2001 11:11:59 -0500 In-Reply-To: Andrew Ho "jdm.h is missing" (Apr 3, 9:03pm) References: <3ACA72EC.DF052698@coredp.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: jdm.h is missing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Apr 3, 9:03pm, Andrew Ho wrote: > Subject: jdm.h is missing > I compile linux-2.4-xfs/cmd/xfsdump/. > > The error messages are as follows: > > attr.c: In function `jdm_attr_list': > attr.c:179: `jdm_filehandle_t' undeclared (first use in this function) > attr.c:179: `filehandle' undeclared (first use in this function) > attr.c:179: warning: statement with no effect > attr.c:180: parse error before `hlen' > attr.c:183: `hlen' undeclared (first use in this function) > attr.c:184: `rval' undeclared (first use in this function) > attr.c:187: warning: control reaches end of non-void function > make[1]: *** [attr.o] Error 1 > You need to have installed the xfsprogs-devel package first, or else do this by hand: # cd linux-2.4-xfs/cmd/xfsprogs # autoconf # ./configure # make # make install install-dev This creates the /usr/include/xfs/jdm.h file you need to build the xfsdump package. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 3 18:48:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f341mnL26474 for linux-xfs-outgoing; Tue, 3 Apr 2001 18:48:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f341mnM26471 for ; Tue, 3 Apr 2001 18:48:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05429 for ; Tue, 3 Apr 2001 18:59:01 -0700 (PDT) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA71324; Wed, 4 Apr 2001 11:47:07 +1000 (EST) Date: Wed, 4 Apr 2001 11:47:07 +1000 (EST) From: Andrew Gildfind Message-Id: <200104040147.LAA71324@snort.melbourne.sgi.com> To: ptg_fsg@larry.melbourne.sgi.com Cc: linux-xfs@oss.sgi.com Subject: TAKE - fsgqa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More qa tweaks... Date: Wed Apr 4 11:45:49 EST 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx Modid: 2.4.x-xfs:slinx:91640a cmd/xfstests/src/fill2fs - 1.4 - add --sync option: sync the filesystem every num bytes written cmd/xfstests/common.rc - 1.6 - improve _do, provide finer control over return status checking and auto exit cmd/xfstests/042 - 1.5 - change order of filesystem flushing to make sure preallocation doesn't use up lots of apparently available disk space, also tweak for new _do command cmd/xfstests/041 - 1.4 - tweak for new _do command From owner-linux-xfs@oss.sgi.com Tue Apr 3 18:52:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f341qDT26532 for linux-xfs-outgoing; Tue, 3 Apr 2001 18:52:13 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f341qCM26529 for ; Tue, 3 Apr 2001 18:52:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA04767 for ; Tue, 3 Apr 2001 19:02:25 -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 LAA86201 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 11:50:35 +1000 (EST) Date: Wed, 4 Apr 2001 11:50:35 +1000 (EST) From: Nathan Scott Message-Id: <200104040150.LAA86201@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - chgrp Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 3 18:48:37 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91641a linux/fs/xfs/xfs_vnodeops.c - 1.495 - fix a silly chgrp bug introduced in the group quota merge. From owner-linux-xfs@oss.sgi.com Tue Apr 3 19:48:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f342mVi27925 for linux-xfs-outgoing; Tue, 3 Apr 2001 19:48:31 -0700 Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f342mUM27922 for ; Tue, 3 Apr 2001 19:48:31 -0700 Received: from thebarn.com (nic-25-c96-008.mn.mediaone.net [24.25.96.8]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f342mD6o095050; Tue, 3 Apr 2001 21:48:17 -0500 (CDT) Message-ID: <3ACA8A98.10C8ABC9@thebarn.com> Date: Tue, 03 Apr 2001 21:44:40 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: "Martin K. Petersen" CC: Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs References: <20010329165519.A7386@tecosim.de> <3ACA530B.E9ECD29D@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Martin K. Petersen" wrote: > >>>>> "Russell" == Russell Cattelan writes: > > >> /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) > ^^^ > > I just noticed this - we don't support kio with LVM. Hmm good point. I assume the option has no affect at this point, but it still would be worth turning it off and see what happens. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Tue Apr 3 21:13:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f344Dnp31124 for linux-xfs-outgoing; Tue, 3 Apr 2001 21:13:49 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f344DmM31121 for ; Tue, 3 Apr 2001 21:13:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA05719 for ; Tue, 3 Apr 2001 21:24:01 -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 OAA83987 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 14:12:09 +1000 (EST) Date: Wed, 4 Apr 2001 14:12:09 +1000 (EST) From: Nathan Scott Message-Id: <200104040412.OAA83987@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - srcdiff Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 3 21:11:07 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91647a cmd/xfsprogs/libxfs/xfs_btree.c - 1.2 cmd/xfsprogs/libxfs/xfs.h - 1.4 cmd/xfsprogs/include/xfs_btree.h - 1.2 cmd/xfsprogs/doc/CHANGES - 1.13 - sync with Steves recent kernel changes in xfs_btree code. cmd/xfsprogs/VERSION - 1.12 - bump minor version number. From owner-linux-xfs@oss.sgi.com Tue Apr 3 21:48:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f344mgP31979 for linux-xfs-outgoing; Tue, 3 Apr 2001 21:48:42 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f344mgM31972 for ; Tue, 3 Apr 2001 21:48:42 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA16853 for ; Tue, 3 Apr 2001 21:47:26 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA20500; Tue, 3 Apr 2001 21:42:07 -0700 (PDT) Message-ID: <3ACAA6F1.EB6C6B7F@sgi.com> Date: Tue, 03 Apr 2001 21:45:37 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russell Cattelan CC: "Martin K. Petersen" , Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs References: <20010329165519.A7386@tecosim.de> <3ACA530B.E9ECD29D@thebarn.com> <3ACA8A98.10C8ABC9@thebarn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan wrote: > > "Martin K. Petersen" wrote: > > > >>>>> "Russell" == Russell Cattelan writes: > > > > >> /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) > > ^^^ > > > > I just noticed this - we don't support kio with LVM. > > Hmm good point. > I assume the option has no affect at this point, but it still would > be worth turning it off and see what happens. Apparently Utz already tried this: ------------- btw: i test it without the kio,logbufs=4,logbsize=32768 mount option, it hangs also. -------------- See http://linux-xfs.sgi.com/projects/xfs/indexed/msg03989.html -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Apr 3 22:48:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f345mE001425 for linux-xfs-outgoing; Tue, 3 Apr 2001 22:48:14 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f345mBM01419 for ; Tue, 3 Apr 2001 22:48:11 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA21087 for ; Tue, 3 Apr 2001 22:46:55 -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 PAA02055 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 15:46:32 +1000 (EST) Date: Wed, 4 Apr 2001 15:46:32 +1000 (EST) From: Nathan Scott Message-Id: <200104040546.PAA02055@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - qa Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 3 22:11:45 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91648a linux/fs/xfs/linux/xfs_linux.h - 1.45 - remove dependence on NR_DQUOTS as this is no longer there in the -ac series of Linux patches (removed from linux/quota.h). Date: Tue Apr 3 22:42:33 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91650a cmd/xfstests/050.grpquota - 1.1 cmd/xfstests/018.grpquota - 1.1 cmd/xfstests/018.ugquota - 1.1 cmd/xfstests/050.usrquota - 1.2 cmd/xfstests/050.uqnoenforce - 1.2 cmd/xfstests/050 - 1.6 cmd/xfstests/018 - 1.3 cmd/xfstests/018.usrquota - 1.3 - updates to match top of tree, grpquota support, fix output to match 3.01 quota user tools. cmd/xfstests/054.out - 1.1 cmd/xfstests/054 - 1.1 - exercise chown/chgrp behavior, ensure consistency with & without various forms of quota. cmd/xfstests/050.gqnoenforce - 1.1 - updates to match top of tree, grpquota support, fix output to match 3.01 quota user tools. cmd/xfstests/common.quota - 1.7 - fix repquota filtering for unambiguous output with quota 3.01 tools. From owner-linux-xfs@oss.sgi.com Tue Apr 3 23:22:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f346Mqx02632 for linux-xfs-outgoing; Tue, 3 Apr 2001 23:22:52 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f346MpM02629 for ; Tue, 3 Apr 2001 23:22:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA6951428 for ; Wed, 4 Apr 2001 08:22:48 +0200 (CEST) mail_from (ajag@snort.melbourne.sgi.com) Received: (from ajag@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA87576 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 16:21:10 +1000 (EST) Date: Wed, 4 Apr 2001 16:21:10 +1000 (EST) From: Andrew Gildfind Message-Id: <200104040621.QAA87576@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_fsr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adds O_DIRECT, xfs_fsr now seems to pass the qa (042) reliably with the current t-o-t so I'm checking this in. I've opened a bug (820093) for monitoring xfs_fsr/direct io issues. Date: Tue Apr 3 23:19:00 PDT 2001 Workarea: snort.melbourne.sgi.com:/home/ajag/isms/slinx The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91653a cmd/xfsdump/fsr/xfs_fsr.c - 1.3 - Add O_DIRECT From owner-linux-xfs@oss.sgi.com Wed Apr 4 01:37:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f348bPN05537 for linux-xfs-outgoing; Wed, 4 Apr 2001 01:37:25 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f348bGM05528 for ; Wed, 4 Apr 2001 01:37:17 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.9.3/8.9.3) with ESMTP id KAA05777 for ; Wed, 4 Apr 2001 10:34:50 +0200 X-Authentication-Warning: quasar.sif.it: matteo owned process doing -bs Date: Wed, 4 Apr 2001 10:34:50 +0200 (CEST) From: Matteo Centonza To: linux-xfs@oss.sgi.com Subject: NFS+RAID5 oops Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1702689938-1339662091-986371775=:5540" Content-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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. ---1702689938-1339662091-986371775=:5540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Dear All, congratulations for the great work. This oops refers to the PR 10 as of 2001-03-21. My test system (RH 7.0) has three ide disks: WDC AC36400L (6.4 Gb) QUANTUM FIREBALL540A (540 Mb) QUANTUM LP120A GM120A01X (120 Mb) on a dual channel controller (ASUS P2B motherboard, Celeron 400 Mhz) in raid 5 configuration (XFS, no mount or mkfs options used). I've run the bonnie++ test (v. 1.01) without problems (except for the poor rating ;-)). I've NFS exported and mounted (locally through net loopback) my RAID5 partition and while i was copying a file bigger than the remaining filesystem size, the oops (repeated twice, output through ksymoops attached) arose instead of the "no space left on device" error. hope this helps, M.C. ---1702689938-1339662091-986371775=:5540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="xfs-nfs-raid5-end-of-media.oops" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="xfs-nfs-raid5-end-of-media.oops" QXByICA0IDAxOjQ5OjMxIHNwZWVkc3RlciBrZXJuZWw6IEJhZCB3cml0ZSBv biBwYWdlIDB4YzEwMjlkYjQNCkFwciAgNCAwMTo0OTozMSBzcGVlZHN0ZXIg a2VybmVsOiBCYWQgd3JpdGUgb24gcGFnZSAweGMxMDI5ZDcwDQpBcHIgIDQg MDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDoga2VybmVsIEJVRyBhdCBwYWdl X2J1Zl9pby5jOjkwNiENCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2Vy bmVsOiBpbnZhbGlkIG9wZXJhbmQ6IDAwMDANCkFwciAgNCAwMTo0OTozNCBz cGVlZHN0ZXIga2VybmVsOiBDUFU6ICAgIDANCkFwciAgNCAwMTo0OTozNCBz cGVlZHN0ZXIga2VybmVsOiBFSVA6ICAgIDAwMTA6W2hvb2tfYnVmZmVyc190 b19wYWdlX2RlbGF5KzM2LzEwMF0NCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0 ZXIga2VybmVsOiBFRkxBR1M6IDAwMDEwMjgyDQpBcHIgIDQgMDE6NDk6MzQg c3BlZWRzdGVyIGtlcm5lbDogZWF4OiAwMDAwMDAyMSAgIGVieDogYzEwMjlk YjQgICBlY3g6IDAwMDAwMDAwICAgZWR4OiBmJA0KQXByICA0IDAxOjQ5OjM0 IHNwZWVkc3RlciBrZXJuZWw6IGVzaTogYzIxNDc5YzAgICBlZGk6IGMwOWRh MDAwICAgZWJwOiBjMWJhNTVjMCAgIGVzcDogYyQNCkFwciAgNCAwMTo0OToz NCBzcGVlZHN0ZXIga2VybmVsOiBkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6 IDAwMTgNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiBQcm9j ZXNzIG5mc2QgKHBpZDogNDUwLCBzdGFja3BhZ2U9YzJkNGYwMDApDQpBcHIg IDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogU3RhY2s6IGMwMzBmOTg1 IGMwMzBmYWM3IDAwMDAwMzhhIGMyMTQ3OWMwIDAwMDAwMDAwIGMwJA0KQXBy ICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICAwMDAwMTAw MCBjMDFiNzZkNCBjMjE0NzljMCBjMTAyOWRiNCAwMDAwMDAwMCAwMCQNCkFw ciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiAgICAgICAgZmZmZmZm ZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEwMDAgMDAkDQpB cHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogQ2FsbCBUcmFjZTog W19fcGJfYmxvY2tfY29tbWl0X3dyaXRlX2FzeW5jKzY5Lzc2XSBbcGFnJA0K QXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICBbbGlu dmZzX3dyaXRlKzI3Ni8zMjBdIFtuZnNkX3dyaXRlKzMyMC82ODBdIFtuZiQN CkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOg0KQXByICA0IDAx OjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IENvZGU6IDBmIDBiIDgzIGM0IDBj IDY4IDAwIDEwIDAwIDAwIDBmIGI3IDQ2IDI4IDUwIDUzICQNCg0K ---1702689938-1339662091-986371775=:5540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="xfs-nfs-raid5-end-of-media.ksymoops" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="xfs-nfs-raid5-end-of-media.ksymoops" a3N5bW9vcHMgMi4zLjQgb24gaTY4NiAyLjQuMi1TR0lfWEZTXzAuMTAtMS4g IE9wdGlvbnMgdXNlZA0KICAgICAtViAoZGVmYXVsdCkNCiAgICAgLWsgL3By b2Mva3N5bXMgKGRlZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRl ZmF1bHQpDQogICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMi1TR0lfWEZTXzAu MTAtMS8gKGRlZmF1bHQpDQogICAgIC1tIC9ib290L1N5c3RlbS5tYXAtMi40 LjItU0dJX1hGU18wLjEwLTEgKHNwZWNpZmllZCkNCg0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHBhcnRpdGlvbl9uYW1l ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDI5YjEyMCwgU3lzdGVtLm1hcCBzYXlz IGMwMTRjYjYwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KQXByICA0 IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IGludmFsaWQgb3BlcmFuZDog MDAwMA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IENQVTog ICAgMA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IEVJUDog ICAgMDAxMDpbaG9va19idWZmZXJzX3RvX3BhZ2VfZGVsYXkrMzYvMTAwXQ0K QXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IEVGTEFHUzogMDAw MTAyODINCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiBlYXg6 IDAwMDAwMDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBl ZHg6IGYkDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogZXNp OiBjMjE0NzljMCAgIGVkaTogYzA5ZGEwMDAgICBlYnA6IGMxYmE1NWMwICAg ZXNwOiBjJA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IGRz OiAwMDE4ICAgZXM6IDAwMTggICBzczogMDAxOA0KQXByICA0IDAxOjQ5OjM0 IHNwZWVkc3RlciBrZXJuZWw6IFByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0 YWNrcGFnZT1jMmQ0ZjAwMCkNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIg a2VybmVsOiBTdGFjazogYzAzMGY5ODUgYzAzMGZhYzcgMDAwMDAzOGEgYzIx NDc5YzAgMDAwMDAwMDAgYzAkDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVy IGtlcm5lbDogICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMx MDI5ZGI0IDAwMDAwMDAwIDAwJA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3Rl ciBrZXJuZWw6ICAgICAgICBmZmZmZmZmZiAwMDAwMTAwMCBjMmQ0ZmNlOCBj MmQ0ZmNmNCAwMDAwMTAwMCAwMCQNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0 ZXIga2VybmVsOiBDYWxsIFRyYWNlOiBbX19wYl9ibG9ja19jb21taXRfd3Jp dGVfYXN5bmMrNjkvNzZdIFtwYWckDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRz dGVyIGtlcm5lbDogQ29kZTogMGYgMGIgODMgYzQgMGMgNjggMDAgMTAgMDAg MDAgMGYgYjcgNDYgMjggNTAgNTMgJA0KV2FybmluZyAoT29wc19jb2RlKTog dHJhaWxpbmcgZ2FyYmFnZSBpZ25vcmVkIG9uIENvZGU6IGxpbmUNCiAgVGV4 dDogJ0NvZGU6IDBmIDBiIDgzIGM0IDBjIDY4IDAwIDEwIDAwIDAwIDBmIGI3 IDQ2IDI4IDUwIDUzICQnDQogIEdhcmJhZ2U6ICcgJCcNClVzaW5nIGRlZmF1 bHRzIGZyb20ga3N5bW9vcHMgLXQgZWxmMzItaTM4NiAtYSBpMzg2DQoNCkNv ZGU7ICAwMDAwMDAwMCBCZWZvcmUgZmlyc3Qgc3ltYm9sDQowMDAwMDAwMCA8 X0VJUD46DQpDb2RlOyAgMDAwMDAwMDAgQmVmb3JlIGZpcnN0IHN5bWJvbA0K ICAgMDogICAwZiAwYiAgICAgICAgICAgICAgICAgICAgIHVkMmEgICANCkNv ZGU7ICAwMDAwMDAwMiBCZWZvcmUgZmlyc3Qgc3ltYm9sDQogICAyOiAgIDgz IGM0IDBjICAgICAgICAgICAgICAgICAgYWRkICAgICQweGMsJWVzcA0KQ29k ZTsgIDAwMDAwMDA1IEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAgIDU6ICAgNjgg MDAgMTAgMDAgMDAgICAgICAgICAgICBwdXNoICAgJDB4MTAwMA0KQ29kZTsg IDAwMDAwMDBhIEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAgIGE6ICAgMGYgYjcg NDYgMjggICAgICAgICAgICAgICBtb3Z6d2wgMHgyOCglZXNpKSwlZWF4DQpD b2RlOyAgMDAwMDAwMGUgQmVmb3JlIGZpcnN0IHN5bWJvbA0KICAgZTogICA1 MCAgICAgICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWF4DQpDb2RlOyAg MDAwMDAwMGYgQmVmb3JlIGZpcnN0IHN5bWJvbA0KICAgZjogICA1MyAgICAg ICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWJ4DQoNCg0KMiB3YXJuaW5n cyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3QgYmUgcmVsaWFibGUuDQo= ---1702689938-1339662091-986371775=:5540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="second.oops" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="second.oops" QmFkIHdyaXRlIG9uIHBhZ2UgMHhjMTAyOWRiNA0KQmFkIHdyaXRlIG9uIHBh Z2UgMHhjMTAyOWQ3MA0Ka2VybmVsIEJVRyBhdCBwYWdlX2J1Zl9pby5jOjkw NiENCmludmFsaWQgb3BlcmFuZDogMDAwMA0KQ1BVOiAgICAwDQpFSVA6ICAg IDAwMTA6WzxjMDFiODE3MD5dDQpFRkxBR1M6IDAwMDEwMjgyDQplYXg6IDAw MDAwMDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBlZHg6 IGZmZmZmZmZmDQplc2k6IGMyMTQ3OWMwICAgZWRpOiBjMDlkYTAwMCAgIGVi cDogYzFiYTU1YzAgICBlc3A6IGMyZDRmYzkwDQpkczogMDAxOCAgIGVzOiAw MDE4ICAgc3M6IDAwMTgNClByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0YWNr cGFnZT1jMmQ0ZjAwMCkNClN0YWNrOiBjMDMwZjk4NSBjMDMwZmFjNyAwMDAw MDM4YSBjMjE0NzljMCAwMDAwMDAwMCBjMDFiODY4NSBjMjE0NzljMCBjMTAy OWRiNA0KICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMxMDI5 ZGI0IDAwMDAwMDAwIDAwMDAxMDAwIDAwMDAwMDAwIGMxYmE1NWMwDQogICAg ICAgZmZmZmZmZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEw MDAgMDAwMDAwMDAgYzEwMjlkYjQgMDAwMDAwMDANCkNhbGwgVHJhY2U6IFs8 YzAxYjg2ODU+XSBbPGMwMWI3NmQ0Pl0gWzxjMDIyNzlmYj5dIFs8YzAyMDJm YTQ+XSBbPGMwMjAzMDgwPl0gWzxjMDFkZWZjYz5dIFs8YzAyMjdmYmU+XQ0K ICAgICAgIFs8YzAyMjQwOTg+XSBbPGMwMTc5YzE4Pl0gWzxjMDJhZTlmMj5d IFs8YzAxNzZkYzc+XSBbPGMwMTc2NDczPl0gWzxjMDJkYjhmOD5dIFs8YzAx NzYyNDE+XSBbPGMwMTA3NDRmPl0NCg0KQ29kZTogMGYgMGIgODMgYzQgMGMg NjggMDAgMTAgMDAgMDAgMGYgYjcgNDYgMjggNTAgNTMgZTggNGIgNzQgZjcN Cg0K ---1702689938-1339662091-986371775=:5540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="second.ksymoops" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="second.ksymoops" a3N5bW9vcHMgMi4zLjQgb24gaTY4NiAyLjQuMi1TR0lfWEZTXzAuMTAtMS4g IE9wdGlvbnMgdXNlZA0KICAgICAtViAoZGVmYXVsdCkNCiAgICAgLWsgL3By b2Mva3N5bXMgKGRlZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRl ZmF1bHQpDQogICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMi1TR0lfWEZTXzAu MTAtMS8gKGRlZmF1bHQpDQogICAgIC1tIC9ib290L1N5c3RlbS5tYXAtMi40 LjItU0dJX1hGU18wLjEwLTEgKHNwZWNpZmllZCkNCg0KV2FybmluZyAoY29t cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHBhcnRpdGlvbl9uYW1l ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDI5YjEyMCwgU3lzdGVtLm1hcCBzYXlz IGMwMTRjYjYwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KaW52YWxp ZCBvcGVyYW5kOiAwMDAwDQpDUFU6ICAgIDANCkVJUDogICAgMDAxMDpbPGMw MWI4MTcwPl0NClVzaW5nIGRlZmF1bHRzIGZyb20ga3N5bW9vcHMgLXQgZWxm MzItaTM4NiAtYSBpMzg2DQpFRkxBR1M6IDAwMDEwMjgyDQplYXg6IDAwMDAw MDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBlZHg6IGZm ZmZmZmZmDQplc2k6IGMyMTQ3OWMwICAgZWRpOiBjMDlkYTAwMCAgIGVicDog YzFiYTU1YzAgICBlc3A6IGMyZDRmYzkwDQpkczogMDAxOCAgIGVzOiAwMDE4 ICAgc3M6IDAwMTgNClByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0YWNrcGFn ZT1jMmQ0ZjAwMCkNClN0YWNrOiBjMDMwZjk4NSBjMDMwZmFjNyAwMDAwMDM4 YSBjMjE0NzljMCAwMDAwMDAwMCBjMDFiODY4NSBjMjE0NzljMCBjMTAyOWRi NA0KICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMxMDI5ZGI0 IDAwMDAwMDAwIDAwMDAxMDAwIDAwMDAwMDAwIGMxYmE1NWMwDQogICAgICAg ZmZmZmZmZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEwMDAg MDAwMDAwMDAgYzEwMjlkYjQgMDAwMDAwMDANCkNhbGwgVHJhY2U6IFs8YzAx Yjg2ODU+XSBbPGMwMWI3NmQ0Pl0gWzxjMDIyNzlmYj5dIFs8YzAyMDJmYTQ+ XSBbPGMwMjAzMDgwPl0gWzxjMDFkZWZjYz5dIFs8YzAyMjdmYmU+XQ0KICAg ICAgIFs8YzAyMjQwOTg+XSBbPGMwMTc5YzE4Pl0gWzxjMDJhZTlmMj5dIFs8 YzAxNzZkYzc+XSBbPGMwMTc2NDczPl0gWzxjMDJkYjhmOD5dIFs8YzAxNzYy NDE+XSBbPGMwMTA3NDRmPl0NCkNvZGU6IDBmIDBiIDgzIGM0IDBjIDY4IDAw IDEwIDAwIDAwIDBmIGI3IDQ2IDI4IDUwIDUzIGU4IDRiIDc0IGY3DQoNCj4+ RUlQOyBjMDFiODE3MCA8aG9va19idWZmZXJzX3RvX3BhZ2VfZGVsYXkrMjQv NjQ+ICAgPD09PT09DQpUcmFjZTsgYzAxYjg2ODUgPF9fcGJfYmxvY2tfY29t bWl0X3dyaXRlX2FzeW5jKzQ1LzRjPg0KVHJhY2U7IGMwMWI3NmQ0IDxwYWdl YnVmX2lvemVybytmMC8xNmM+DQpUcmFjZTsgYzAyMjc5ZmIgPHhmc196ZXJv X2VvZiszMWIvNWQ0Pg0KVHJhY2U7IGMwMjAyZmE0IDx4ZnNfaWxvY2srMC8x OD4NClRyYWNlOyBjMDIwMzA4MCA8eGZzX2l1bmxvY2srMC82OD4NClRyYWNl OyBjMDFkZWZjYyA8eGZzX2JtYXBpKzAvMTJkOD4NClRyYWNlOyBjMDIyN2Zi ZSA8eGZzX3dyaXRlKzMwYS82NjA+DQpUcmFjZTsgYzAyMjQwOTggPGxpbnZm c193cml0ZSsxMTQvMTQwPg0KVHJhY2U7IGMwMTc5YzE4IDxuZnNkX3dyaXRl KzE0MC8yYTg+DQpUcmFjZTsgYzAyYWU5ZjIgPG5mX2hvb2tfc2xvdytjYS8x MGM+DQpUcmFjZTsgYzAxNzZkYzcgPG5mc2RfcHJvY193cml0ZStjNy9kMD4N ClRyYWNlOyBjMDE3NjQ3MyA8bmZzZF9kaXNwYXRjaCtjYi8xNjg+DQpUcmFj ZTsgYzAyZGI4ZjggPHN2Y19wcm9jZXNzKzJhYy81NDQ+DQpUcmFjZTsgYzAx NzYyNDEgPG5mc2QrMTkxLzJmOD4NClRyYWNlOyBjMDEwNzQ0ZiA8a2VybmVs X3RocmVhZCsyMy8zMD4NCkNvZGU7ICBjMDFiODE3MCA8aG9va19idWZmZXJz X3RvX3BhZ2VfZGVsYXkrMjQvNjQ+DQowMDAwMDAwMCA8X0VJUD46DQpDb2Rl OyAgYzAxYjgxNzAgPGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzI0LzY0 PiAgIDw9PT09PQ0KICAgMDogICAwZiAwYiAgICAgICAgICAgICAgICAgICAg IHVkMmEgICAgICA8PT09PT0NCkNvZGU7ICBjMDFiODE3MiA8aG9va19idWZm ZXJzX3RvX3BhZ2VfZGVsYXkrMjYvNjQ+DQogICAyOiAgIDgzIGM0IDBjICAg ICAgICAgICAgICAgICAgYWRkICAgICQweGMsJWVzcA0KQ29kZTsgIGMwMWI4 MTc1IDxob29rX2J1ZmZlcnNfdG9fcGFnZV9kZWxheSsyOS82ND4NCiAgIDU6 ICAgNjggMDAgMTAgMDAgMDAgICAgICAgICAgICBwdXNoICAgJDB4MTAwMA0K Q29kZTsgIGMwMWI4MTdhIDxob29rX2J1ZmZlcnNfdG9fcGFnZV9kZWxheSsy ZS82ND4NCiAgIGE6ICAgMGYgYjcgNDYgMjggICAgICAgICAgICAgICBtb3Z6 d2wgMHgyOCglZXNpKSwlZWF4DQpDb2RlOyAgYzAxYjgxN2UgPGhvb2tfYnVm ZmVyc190b19wYWdlX2RlbGF5KzMyLzY0Pg0KICAgZTogICA1MCAgICAgICAg ICAgICAgICAgICAgICAgIHB1c2ggICAlZWF4DQpDb2RlOyAgYzAxYjgxN2Yg PGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzMzLzY0Pg0KICAgZjogICA1 MyAgICAgICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWJ4DQpDb2RlOyAg YzAxYjgxODAgPGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzM0LzY0Pg0K ICAxMDogICBlOCA0YiA3NCBmNyAwMCAgICAgICAgICAgIGNhbGwgICBmNzc0 NjAgPF9FSVArMHhmNzc0NjA+IGMxMTJmNWQwIDxfZW5kK2Q0NDFmYy80NDM4 YzJjPg0KDQoNCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3Qg YmUgcmVsaWFibGUuDQo= ---1702689938-1339662091-986371775=:5540-- From owner-linux-xfs@oss.sgi.com Wed Apr 4 04:06:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34B6so11023 for linux-xfs-outgoing; Wed, 4 Apr 2001 04:06:54 -0700 Received: from ns.tecosim.de (ns.tecosim.de [194.24.222.9]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34B6lM11019 for ; Wed, 4 Apr 2001 04:06:47 -0700 Received: from donner.tecosim.de (root@donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA26194; Wed, 4 Apr 2001 13:06:42 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f34B6f603095; Wed, 4 Apr 2001 13:06:41 +0200 Date: Wed, 4 Apr 2001 13:06:41 +0200 From: Utz Lehmann To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs Message-ID: <20010404130641.C1150@tecosim.de> References: <20010329165519.A7386@tecosim.de> <3ACA530B.E9ECD29D@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACA530B.E9ECD29D@thebarn.com>; from cattelan@thebarn.com on Tue, Apr 03, 2001 at 06:47:39PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Russell Cattelan [cattelan@thebarn.com] wrote: > Utz Lehmann wrote: > > > Hi > > > > With newer cvs kernel (cvs from this week, before i had holidays) i have > > problems with my linux workstation (suse 7.1) at work. > > > > Umounting the filesystems while shutdown hangs. > > > > Following partitions are xfs: > > > > /dev/sda1 on / type xfs (rw) > > /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) > > /dev/vg00/var on /var type xfs (rw,kio,logbufs=4,logbsize=32768) > > /dev/vg00/opt on /opt type xfs (rw,kio,logbufs=4,logbsize=32768) > > /dev/vg00/tmp on /tmp type xfs (rw,kio,logbufs=4,logbsize=32768) > > I assume these are lvm volumes? > Could you sent configuration of these volumes. Sorry, i think i send too little information about the system. It's my workstation at my job. It's a thunderbrid 800, 256MB RAM, 18GB IBM DDYS-T18350N attached to a Adaptec 7892A running SuSE 7.1. It has a nvidia TNT2 Graphics using the 0.9-769 glx driver. The kernel and the nvidia kernel module is compiled with the redhat 7.0 kgcc rpm. One tricky thing is that it runs 25 automount processes (to simulate direct maps). It hangs without X and automounter also. ok, here is the lvm configuration (vgdisplay -v). /dev/vg00/usr are xfs. /dev/vg00/USR are ext2 (used by installation and for backup). / is on sda1 (xfs) /boot is on sda2 (ext2) No initrd is used. --- Volume group --- VG Name vg00 VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 10 Open LV 5 MAX LV Size 255.99 GB Max PV 256 Cur PV 1 Act PV 1 VG Size 16.45 GB PE Size 4 MB Total PE 4212 Alloc PE / Size 4212 / 16.45 GB Free PE / Size 0 / 0 VG UUID G8ohzN-Dp3u-GOYz-LZwr-eWD5-zYMc-a1dDwE --- Logical volume --- LV Name /dev/vg00/usr VG Name vg00 LV Write Access read/write LV Status available LV # 1 # open 1 LV Size 4 GB Current LE 1024 Allocated LE 1024 Allocation next free Read ahead sectors 120 Block device 58:0 --- Logical volume --- LV Name /dev/vg00/var VG Name vg00 LV Write Access read/write LV Status available LV # 2 # open 1 LV Size 512 MB Current LE 128 Allocated LE 128 Allocation next free Read ahead sectors 120 Block device 58:1 --- Logical volume --- LV Name /dev/vg00/opt VG Name vg00 LV Write Access read/write LV Status available LV # 3 # open 1 LV Size 2 GB Current LE 512 Allocated LE 512 Allocation next free Read ahead sectors 120 Block device 58:2 --- Logical volume --- LV Name /dev/vg00/tmp VG Name vg00 LV Write Access read/write LV Status available LV # 4 # open 1 LV Size 256 MB Current LE 64 Allocated LE 64 Allocation next free Read ahead sectors 120 Block device 58:3 --- Logical volume --- LV Name /dev/vg00/USR VG Name vg00 LV Write Access read/write LV Status available LV # 5 # open 0 LV Size 4 GB Current LE 1024 Allocated LE 1024 Allocation next free Read ahead sectors 120 Block device 58:4 --- Logical volume --- LV Name /dev/vg00/VAR VG Name vg00 LV Write Access read/write LV Status available LV # 6 # open 0 LV Size 512 MB Current LE 128 Allocated LE 128 Allocation next free Read ahead sectors 120 Block device 58:5 --- Logical volume --- LV Name /dev/vg00/OPT VG Name vg00 LV Write Access read/write LV Status available LV # 7 # open 0 LV Size 2 GB Current LE 512 Allocated LE 512 Allocation next free Read ahead sectors 120 Block device 58:6 --- Logical volume --- LV Name /dev/vg00/TMP VG Name vg00 LV Write Access read/write LV Status available LV # 8 # open 0 LV Size 256 MB Current LE 64 Allocated LE 64 Allocation next free Read ahead sectors 120 Block device 58:7 --- Logical volume --- LV Name /dev/vg00/swap VG Name vg00 LV Write Access read/write LV Status available LV # 9 # open 1 LV Size 256 MB Current LE 64 Allocated LE 64 Allocation next free Read ahead sectors 120 Block device 58:8 --- Logical volume --- LV Name /dev/vg00/test VG Name vg00 LV Write Access read/write LV Status available LV # 10 # open 0 LV Size 2.7 GB Current LE 692 Allocated LE 692 Allocation next free Read ahead sectors 120 Block device 58:9 --- Physical volumes --- PV Name (#) /dev/sda3 (1) PV Status available / allocatable Total PE / Free PE 4212 / 0 > > Also one more kdb command. > kdb> bta > Back trace all. > > We need to find out why the pagebuf pagebuf_delwri_flush is currently > working on has a pin count.... that shouldn't be happening at this point. Entering kdb (current=0xc035a000, pid 0) due to Keyboard Entry kdb> bta Stack traceback for pid 1 EBP EIP Function(args) 0xc15ffefc 0xc0112b18 schedule+0x2d8 (0xc15fff10) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc15fff24 0xc011280a schedule_timeout+0x7a kernel .text 0xc0100000 0xc0112790 0xc0112830 0xc013fd13 do_select+0x93 (0xb, 0xc15fffa8, 0xc15fffa4) kernel .text 0xc0100000 0xc013fc80 0xc013fe90 0xc01402f2 sys_select+0x432 (0xb, 0xbffff93c, 0x0, 0x0, 0xbffff884) kernel .text 0xc0100000 0xc013fec0 0xc0140470 0xc0108f77 system_call+0x33 kernel .text 0xc0100000 0xc0108f44 0xc0108f7c Enter to end, to continue: Stack traceback for pid 2 EBP EIP Function(args) 0xc15f1fa8 0xc0112b18 schedule+0x2d8 (0x700) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc0120015 context_thread+0x115 kernel .text 0xc0100000 0xc011ff00 0xc01200c0 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 3 EBP EIP Function(args) 0xc15edf90 0xc0112b18 schedule+0x2d8 (0xc15edfa4) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc15edfb8 0xc011280a schedule_timeout+0x7a (0x10f00, 0xc0283711, 0xc15ec239) kernel .text 0xc0100000 0xc0112790 0xc0112830 0xc15edfdc 0xc0112e76 interruptible_sleep_on_timeout+0x46 (0xc15fffbc) kernel .text 0xc0100000 0xc0112e30 0xc0112ea0 0xc012b8e9 kswapd+0xe9 kernel .text 0xc0100000 0xc012b800 0xc012b910 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 4 EBP EIP Function(args) 0xc15ebfb0 0xc0112b18 schedule+0x2d8 (0x10f00) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc15ebfcc 0xc0112e10 interruptible_sleep_on+0x40 (0x10f00, 0xc15fffb0) kernel .text 0xc0100000 0xc0112dd0 0xc0112e30 0xc012b9bb kreclaimd+0x5b kernel .text 0xc0100000 0xc012b960 0xc012ba40 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 5 EBP EIP Function(args) 0xc15e9fd8 0xc0112b18 schedule+0x2d8 (0x10f00) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc013526e bdflush+0xce kernel .text 0xc0100000 0xc01351a0 0xc0135280 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 6 EBP EIP Function(args) 0xc15e7f88 0xc0112b18 schedule+0x2d8 kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc01360b3 __wait_on_super+0x73 (0xcf8ab800) kernel .text 0xc0100000 0xc0136040 0xc01360d0 0xc0136115 sync_supers+0x45 (0x0) kernel .text 0xc0100000 0xc01360d0 0xc0136180 0xc0135097 sync_old_buffers+0x7 (0x10f00) kernel .text 0xc0100000 0xc0135090 0xc01350d0 0xc013535c kupdate+0xdc kernel .text 0xc0100000 0xc0135280 0xc0135360 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 7 EBP EIP Function(args) 0xc1581fb4 0xc0112b18 schedule+0x2d8 kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc0235914 md_thread+0x104 kernel .text 0xc0100000 0xc0235810 0xc0235980 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 8 EBP EIP Function(args) 0xc1563f90 0xc0112b18 schedule+0x2d8 (0xced50e00) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc1563fac 0xc0112e10 interruptible_sleep_on+0x40 (0xc1563fdc, 0xc1563fdc, 0xf00) kernel .text 0xc0100000 0xc0112dd0 0xc0112e30 0xc0160534 pagebuf_daemon+0xd4 kernel .text 0xc0100000 0xc0160460 0xc0160690 0xc01074f3 kernel_thread+0x23 kernel .text 0xc0100000 0xc01074d0 0xc0107500 Enter to end, to continue: Stack traceback for pid 1174 EBP EIP Function(args) 0xcdacdf80 0xc0112b18 schedule+0x2d8 (0xcdacc000) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc0117fff sys_wait4+0x37f (0xffffffff, 0xbffff8a0, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0117c80 0xc0118030 0xc0108f77 system_call+0x33 kernel .text 0xc0100000 0xc0108f44 0xc0108f7c Enter to end, to continue: Stack traceback for pid 1561 EBP EIP Function(args) 0xcff13f80 0xc0112b18 schedule+0x2d8 (0xcff12000) kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc0117fff sys_wait4+0x37f (0xffffffff, 0xbffffa00, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0117c80 0xc0118030 0xc0108f77 system_call+0x33 kernel .text 0xc0100000 0xc0108f44 0xc0108f7c Enter to end, to continue: Stack traceback for pid 1582 EBP EIP Function(args) 0xcd5e1e58 0xc0112b18 schedule+0x2d8 kernel .text 0xc0100000 0xc0112840 0xc0112c70 0xc015fb13 pagebuf_iorequest+0x103 (0xced50380) kernel .text 0xc0100000 0xc015fa10 0xc015fba0 0xc01c7c47 xfs_bdstrat_cb+0x27 (0xced50380) kernel .text 0xc0100000 0xc01c7c20 0xc01c7c70 0xc0160763 pagebuf_delwri_flush+0xd3 (0xcf776140, 0x1, 0xcd5e1ec8) kernel .text 0xc0100000 0xc0160690 0xc0160880 0xc01c7d2d XFS_bflush+0x1d (0xcf776140, 0x3a01) kernel .text 0xc0100000 0xc01c7d10 0xc01c7d40 0xc01b6873 xfs_unmount+0xd3 (0xcf701400, 0x0, 0xc03b16a0) kernel .text 0xc0100000 0xc01b67a0 0xc01b6920 0xc01c189a fs_dounmount+0x5a (0xcf701400, 0x0, 0x0, 0xc03b16a0, 0xcf776444) kernel .text 0xc0100000 0xc01c1840 0xc01c18c0 0xc01c8d38 linvfs_put_super+0x58 (0xcf8ab800) kernel .text 0xc0100000 0xc01c8ce0 0xc01c8db0 0xc0136867 kill_super+0x87 (0xcf8ab800, 0x0, 0xcf79e440, 0xffffffff, 0xcfb11940) kernel .text 0xc0100000 0xc01367e0 0xc0136920 0xc0136c71 do_umount+0x1c1 (0xcf79e440, 0x0, 0x0) kernel .text 0xc0100000 0xc0136ab0 0xc0136c80 more> 0xc0136d46 sys_umount+0xc6 (0x8052428, 0x0) kernel .text 0xc0100000 0xc0136c80 0xc0136d80 0xc0136d8c sys_oldumount+0xc (0x8052428, 0x804ee27, 0x8052468, 0x8052429, 0x804ee20) kernel .text 0xc0100000 0xc0136d80 0xc0136d90 0xc0108f77 system_call+0x33 kernel .text 0xc0100000 0xc0108f44 0xc0108f7c Enter to end, to continue: kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc15fe000 00000001 00000000 0 000 stop 0xc15fe260 init 0xc15f0000 00000002 00000001 0 000 stop 0xc15f0260 keventd 0xc15ec000 00000003 00000001 0 000 stop 0xc15ec260 kswapd 0xc15ea000 00000004 00000001 0 000 stop 0xc15ea260 kreclaimd 0xc15e8000 00000005 00000001 0 000 stop 0xc15e8260 bdflush 0xc15e6000 00000006 00000001 0 000 stop 0xc15e6260 kupdate 0xc1580000 00000007 00000001 0 000 stop 0xc1580260 mdrecoveryd 0xc1562000 00000008 00000001 0 000 stop 0xc1562260 pagebuf_daemon 0xcdacc000 00001174 00000001 0 000 stop 0xcdacc260 rc 0xcff12000 00001561 00001174 0 000 stop 0xcff12260 S20reboot 0xcd5e0000 00001582 00001561 0 000 stop 0xcd5e0260 umount kdb> reboot utz From owner-linux-xfs@oss.sgi.com Wed Apr 4 04:33:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34BX8i12467 for linux-xfs-outgoing; Wed, 4 Apr 2001 04:33:08 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34BX6M12464 for ; Wed, 4 Apr 2001 04:33:06 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA07426 for ; Wed, 4 Apr 2001 04:43:20 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1363792; Wed, 4 Apr 2001 06:30:19 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA12498; Wed, 4 Apr 2001 06:30:18 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34BRq203738; Wed, 4 Apr 2001 06:27:52 -0500 Message-Id: <200104041127.f34BRq203738@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin K. Petersen" cc: Russell Cattelan , Utz Lehmann , linux-xfs@oss.sgi.com Subject: Re: shutdown umount hangs In-Reply-To: Message from "Martin K. Petersen" of "03 Apr 2001 19:41:59 EDT." Date: Wed, 04 Apr 2001 06:27:52 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >>>>> "Russell" == Russell Cattelan writes: > > >> /dev/vg00/usr on /usr type xfs (rw,kio,logbufs=4,logbsize=32768) > ^^^ > > I just noticed this - we don't support kio with LVM. > > -- > Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. > mkp@linuxcare.com, http://www.linuxcare.com/ > SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ And now we don't support kio at all! hmm, I removed the mount option maybe I should have left it a noop. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 06:54:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34DsXI18245 for linux-xfs-outgoing; Wed, 4 Apr 2001 06:54:33 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34DsWM18242 for ; Wed, 4 Apr 2001 06:54:32 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA06231 for ; Wed, 4 Apr 2001 07:04:45 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1363683; Wed, 4 Apr 2001 08:53:15 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA90288; Wed, 4 Apr 2001 08:53:15 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34DolS07140; Wed, 4 Apr 2001 08:50:48 -0500 Message-Id: <200104041350.f34DolS07140@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matteo Centonza cc: linux-xfs@oss.sgi.com Subject: Re: NFS+RAID5 oops In-Reply-To: Message from Matteo Centonza of "Wed, 04 Apr 2001 10:34:50 +0200." Date: Wed, 04 Apr 2001 08:50:47 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the report, there is a definite hole in the code logic here, should have a fix sometime today. We are attempting to setup pages as delayed allocate independent of actually knowing if this is the correct state - in your case the page was already allocated on disk, so this was the wrong thing to do. Steve > 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. > > ---1702689938-1339662091-986371775=:5540 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Content-ID: > > Dear All, > > congratulations for the great work. This oops refers to the PR 10 as > of 2001-03-21. My test system (RH 7.0) has three ide disks: > > WDC AC36400L (6.4 Gb) > QUANTUM FIREBALL540A (540 Mb) > QUANTUM LP120A GM120A01X (120 Mb) > > on a dual channel controller (ASUS P2B motherboard, Celeron 400 Mhz) > > in raid 5 configuration (XFS, no mount or mkfs options used). I've run the > bonnie++ test (v. 1.01) without problems (except for the poor rating ;-)). > > I've NFS exported and mounted (locally through net loopback) my RAID5 > partition and while i was copying a file bigger than the remaining > filesystem size, the oops (repeated twice, output through ksymoops > attached) arose instead of the "no space left on device" error. > > hope this helps, > > M.C. > > > ---1702689938-1339662091-986371775=:5540 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="xfs-nfs-raid5-end-of-media. > oops" > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: > Content-Disposition: ATTACHMENT; FILENAME="xfs-nfs-raid5-end-of-media.oops" > > QXByICA0IDAxOjQ5OjMxIHNwZWVkc3RlciBrZXJuZWw6IEJhZCB3cml0ZSBv > biBwYWdlIDB4YzEwMjlkYjQNCkFwciAgNCAwMTo0OTozMSBzcGVlZHN0ZXIg > a2VybmVsOiBCYWQgd3JpdGUgb24gcGFnZSAweGMxMDI5ZDcwDQpBcHIgIDQg > MDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDoga2VybmVsIEJVRyBhdCBwYWdl > X2J1Zl9pby5jOjkwNiENCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2Vy > bmVsOiBpbnZhbGlkIG9wZXJhbmQ6IDAwMDANCkFwciAgNCAwMTo0OTozNCBz > cGVlZHN0ZXIga2VybmVsOiBDUFU6ICAgIDANCkFwciAgNCAwMTo0OTozNCBz > cGVlZHN0ZXIga2VybmVsOiBFSVA6ICAgIDAwMTA6W2hvb2tfYnVmZmVyc190 > b19wYWdlX2RlbGF5KzM2LzEwMF0NCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0 > ZXIga2VybmVsOiBFRkxBR1M6IDAwMDEwMjgyDQpBcHIgIDQgMDE6NDk6MzQg > c3BlZWRzdGVyIGtlcm5lbDogZWF4OiAwMDAwMDAyMSAgIGVieDogYzEwMjlk > YjQgICBlY3g6IDAwMDAwMDAwICAgZWR4OiBmJA0KQXByICA0IDAxOjQ5OjM0 > IHNwZWVkc3RlciBrZXJuZWw6IGVzaTogYzIxNDc5YzAgICBlZGk6IGMwOWRh > MDAwICAgZWJwOiBjMWJhNTVjMCAgIGVzcDogYyQNCkFwciAgNCAwMTo0OToz > NCBzcGVlZHN0ZXIga2VybmVsOiBkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6 > IDAwMTgNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiBQcm9j > ZXNzIG5mc2QgKHBpZDogNDUwLCBzdGFja3BhZ2U9YzJkNGYwMDApDQpBcHIg > IDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogU3RhY2s6IGMwMzBmOTg1 > IGMwMzBmYWM3IDAwMDAwMzhhIGMyMTQ3OWMwIDAwMDAwMDAwIGMwJA0KQXBy > ICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICAwMDAwMTAw > MCBjMDFiNzZkNCBjMjE0NzljMCBjMTAyOWRiNCAwMDAwMDAwMCAwMCQNCkFw > ciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiAgICAgICAgZmZmZmZm > ZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEwMDAgMDAkDQpB > cHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogQ2FsbCBUcmFjZTog > W19fcGJfYmxvY2tfY29tbWl0X3dyaXRlX2FzeW5jKzY5Lzc2XSBbcGFnJA0K > QXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6ICAgICAgICBbbGlu > dmZzX3dyaXRlKzI3Ni8zMjBdIFtuZnNkX3dyaXRlKzMyMC82ODBdIFtuZiQN > CkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOg0KQXByICA0IDAx > OjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IENvZGU6IDBmIDBiIDgzIGM0IDBj > IDY4IDAwIDEwIDAwIDAwIDBmIGI3IDQ2IDI4IDUwIDUzICQNCg0K > ---1702689938-1339662091-986371775=:5540 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="xfs-nfs-raid5-end-of-media. > ksymoops" > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: > Content-Disposition: ATTACHMENT; FILENAME="xfs-nfs-raid5-end-of-media.ksymoop > s" > > a3N5bW9vcHMgMi4zLjQgb24gaTY4NiAyLjQuMi1TR0lfWEZTXzAuMTAtMS4g > IE9wdGlvbnMgdXNlZA0KICAgICAtViAoZGVmYXVsdCkNCiAgICAgLWsgL3By > b2Mva3N5bXMgKGRlZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRl > ZmF1bHQpDQogICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMi1TR0lfWEZTXzAu > MTAtMS8gKGRlZmF1bHQpDQogICAgIC1tIC9ib290L1N5c3RlbS5tYXAtMi40 > LjItU0dJX1hGU18wLjEwLTEgKHNwZWNpZmllZCkNCg0KV2FybmluZyAoY29t > cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHBhcnRpdGlvbl9uYW1l > ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDI5YjEyMCwgU3lzdGVtLm1hcCBzYXlz > IGMwMTRjYjYwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KQXByICA0 > IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IGludmFsaWQgb3BlcmFuZDog > MDAwMA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IENQVTog > ICAgMA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IEVJUDog > ICAgMDAxMDpbaG9va19idWZmZXJzX3RvX3BhZ2VfZGVsYXkrMzYvMTAwXQ0K > QXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IEVGTEFHUzogMDAw > MTAyODINCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIga2VybmVsOiBlYXg6 > IDAwMDAwMDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBl > ZHg6IGYkDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVyIGtlcm5lbDogZXNp > OiBjMjE0NzljMCAgIGVkaTogYzA5ZGEwMDAgICBlYnA6IGMxYmE1NWMwICAg > ZXNwOiBjJA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3RlciBrZXJuZWw6IGRz > OiAwMDE4ICAgZXM6IDAwMTggICBzczogMDAxOA0KQXByICA0IDAxOjQ5OjM0 > IHNwZWVkc3RlciBrZXJuZWw6IFByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0 > YWNrcGFnZT1jMmQ0ZjAwMCkNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0ZXIg > a2VybmVsOiBTdGFjazogYzAzMGY5ODUgYzAzMGZhYzcgMDAwMDAzOGEgYzIx > NDc5YzAgMDAwMDAwMDAgYzAkDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRzdGVy > IGtlcm5lbDogICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMx > MDI5ZGI0IDAwMDAwMDAwIDAwJA0KQXByICA0IDAxOjQ5OjM0IHNwZWVkc3Rl > ciBrZXJuZWw6ICAgICAgICBmZmZmZmZmZiAwMDAwMTAwMCBjMmQ0ZmNlOCBj > MmQ0ZmNmNCAwMDAwMTAwMCAwMCQNCkFwciAgNCAwMTo0OTozNCBzcGVlZHN0 > ZXIga2VybmVsOiBDYWxsIFRyYWNlOiBbX19wYl9ibG9ja19jb21taXRfd3Jp > dGVfYXN5bmMrNjkvNzZdIFtwYWckDQpBcHIgIDQgMDE6NDk6MzQgc3BlZWRz > dGVyIGtlcm5lbDogQ29kZTogMGYgMGIgODMgYzQgMGMgNjggMDAgMTAgMDAg > MDAgMGYgYjcgNDYgMjggNTAgNTMgJA0KV2FybmluZyAoT29wc19jb2RlKTog > dHJhaWxpbmcgZ2FyYmFnZSBpZ25vcmVkIG9uIENvZGU6IGxpbmUNCiAgVGV4 > dDogJ0NvZGU6IDBmIDBiIDgzIGM0IDBjIDY4IDAwIDEwIDAwIDAwIDBmIGI3 > IDQ2IDI4IDUwIDUzICQnDQogIEdhcmJhZ2U6ICcgJCcNClVzaW5nIGRlZmF1 > bHRzIGZyb20ga3N5bW9vcHMgLXQgZWxmMzItaTM4NiAtYSBpMzg2DQoNCkNv > ZGU7ICAwMDAwMDAwMCBCZWZvcmUgZmlyc3Qgc3ltYm9sDQowMDAwMDAwMCA8 > X0VJUD46DQpDb2RlOyAgMDAwMDAwMDAgQmVmb3JlIGZpcnN0IHN5bWJvbA0K > ICAgMDogICAwZiAwYiAgICAgICAgICAgICAgICAgICAgIHVkMmEgICANCkNv > ZGU7ICAwMDAwMDAwMiBCZWZvcmUgZmlyc3Qgc3ltYm9sDQogICAyOiAgIDgz > IGM0IDBjICAgICAgICAgICAgICAgICAgYWRkICAgICQweGMsJWVzcA0KQ29k > ZTsgIDAwMDAwMDA1IEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAgIDU6ICAgNjgg > MDAgMTAgMDAgMDAgICAgICAgICAgICBwdXNoICAgJDB4MTAwMA0KQ29kZTsg > IDAwMDAwMDBhIEJlZm9yZSBmaXJzdCBzeW1ib2wNCiAgIGE6ICAgMGYgYjcg > NDYgMjggICAgICAgICAgICAgICBtb3Z6d2wgMHgyOCglZXNpKSwlZWF4DQpD > b2RlOyAgMDAwMDAwMGUgQmVmb3JlIGZpcnN0IHN5bWJvbA0KICAgZTogICA1 > MCAgICAgICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWF4DQpDb2RlOyAg > MDAwMDAwMGYgQmVmb3JlIGZpcnN0IHN5bWJvbA0KICAgZjogICA1MyAgICAg > ICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWJ4DQoNCg0KMiB3YXJuaW5n > cyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3QgYmUgcmVsaWFibGUuDQo= > ---1702689938-1339662091-986371775=:5540 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="second.oops" > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: > Content-Disposition: ATTACHMENT; FILENAME="second.oops" > > QmFkIHdyaXRlIG9uIHBhZ2UgMHhjMTAyOWRiNA0KQmFkIHdyaXRlIG9uIHBh > Z2UgMHhjMTAyOWQ3MA0Ka2VybmVsIEJVRyBhdCBwYWdlX2J1Zl9pby5jOjkw > NiENCmludmFsaWQgb3BlcmFuZDogMDAwMA0KQ1BVOiAgICAwDQpFSVA6ICAg > IDAwMTA6WzxjMDFiODE3MD5dDQpFRkxBR1M6IDAwMDEwMjgyDQplYXg6IDAw > MDAwMDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBlZHg6 > IGZmZmZmZmZmDQplc2k6IGMyMTQ3OWMwICAgZWRpOiBjMDlkYTAwMCAgIGVi > cDogYzFiYTU1YzAgICBlc3A6IGMyZDRmYzkwDQpkczogMDAxOCAgIGVzOiAw > MDE4ICAgc3M6IDAwMTgNClByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0YWNr > cGFnZT1jMmQ0ZjAwMCkNClN0YWNrOiBjMDMwZjk4NSBjMDMwZmFjNyAwMDAw > MDM4YSBjMjE0NzljMCAwMDAwMDAwMCBjMDFiODY4NSBjMjE0NzljMCBjMTAy > OWRiNA0KICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMxMDI5 > ZGI0IDAwMDAwMDAwIDAwMDAxMDAwIDAwMDAwMDAwIGMxYmE1NWMwDQogICAg > ICAgZmZmZmZmZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEw > MDAgMDAwMDAwMDAgYzEwMjlkYjQgMDAwMDAwMDANCkNhbGwgVHJhY2U6IFs8 > YzAxYjg2ODU+XSBbPGMwMWI3NmQ0Pl0gWzxjMDIyNzlmYj5dIFs8YzAyMDJm > YTQ+XSBbPGMwMjAzMDgwPl0gWzxjMDFkZWZjYz5dIFs8YzAyMjdmYmU+XQ0K > ICAgICAgIFs8YzAyMjQwOTg+XSBbPGMwMTc5YzE4Pl0gWzxjMDJhZTlmMj5d > IFs8YzAxNzZkYzc+XSBbPGMwMTc2NDczPl0gWzxjMDJkYjhmOD5dIFs8YzAx > NzYyNDE+XSBbPGMwMTA3NDRmPl0NCg0KQ29kZTogMGYgMGIgODMgYzQgMGMg > NjggMDAgMTAgMDAgMDAgMGYgYjcgNDYgMjggNTAgNTMgZTggNGIgNzQgZjcN > Cg0K > ---1702689938-1339662091-986371775=:5540 > Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="second.ksymoops" > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: > Content-Disposition: ATTACHMENT; FILENAME="second.ksymoops" > > a3N5bW9vcHMgMi4zLjQgb24gaTY4NiAyLjQuMi1TR0lfWEZTXzAuMTAtMS4g > IE9wdGlvbnMgdXNlZA0KICAgICAtViAoZGVmYXVsdCkNCiAgICAgLWsgL3By > b2Mva3N5bXMgKGRlZmF1bHQpDQogICAgIC1sIC9wcm9jL21vZHVsZXMgKGRl > ZmF1bHQpDQogICAgIC1vIC9saWIvbW9kdWxlcy8yLjQuMi1TR0lfWEZTXzAu > MTAtMS8gKGRlZmF1bHQpDQogICAgIC1tIC9ib290L1N5c3RlbS5tYXAtMi40 > LjItU0dJX1hGU18wLjEwLTEgKHNwZWNpZmllZCkNCg0KV2FybmluZyAoY29t > cGFyZV9tYXBzKTogbWlzbWF0Y2ggb24gc3ltYm9sIHBhcnRpdGlvbl9uYW1l > ICAsIGtzeW1zX2Jhc2Ugc2F5cyBjMDI5YjEyMCwgU3lzdGVtLm1hcCBzYXlz > IGMwMTRjYjYwLiAgSWdub3Jpbmcga3N5bXNfYmFzZSBlbnRyeQ0KaW52YWxp > ZCBvcGVyYW5kOiAwMDAwDQpDUFU6ICAgIDANCkVJUDogICAgMDAxMDpbPGMw > MWI4MTcwPl0NClVzaW5nIGRlZmF1bHRzIGZyb20ga3N5bW9vcHMgLXQgZWxm > MzItaTM4NiAtYSBpMzg2DQpFRkxBR1M6IDAwMDEwMjgyDQplYXg6IDAwMDAw > MDIxICAgZWJ4OiBjMTAyOWRiNCAgIGVjeDogMDAwMDAwMDAgICBlZHg6IGZm > ZmZmZmZmDQplc2k6IGMyMTQ3OWMwICAgZWRpOiBjMDlkYTAwMCAgIGVicDog > YzFiYTU1YzAgICBlc3A6IGMyZDRmYzkwDQpkczogMDAxOCAgIGVzOiAwMDE4 > ICAgc3M6IDAwMTgNClByb2Nlc3MgbmZzZCAocGlkOiA0NTAsIHN0YWNrcGFn > ZT1jMmQ0ZjAwMCkNClN0YWNrOiBjMDMwZjk4NSBjMDMwZmFjNyAwMDAwMDM4 > YSBjMjE0NzljMCAwMDAwMDAwMCBjMDFiODY4NSBjMjE0NzljMCBjMTAyOWRi > NA0KICAgICAgIDAwMDAxMDAwIGMwMWI3NmQ0IGMyMTQ3OWMwIGMxMDI5ZGI0 > IDAwMDAwMDAwIDAwMDAxMDAwIDAwMDAwMDAwIGMxYmE1NWMwDQogICAgICAg > ZmZmZmZmZmYgMDAwMDEwMDAgYzJkNGZjZTggYzJkNGZjZjQgMDAwMDEwMDAg > MDAwMDAwMDAgYzEwMjlkYjQgMDAwMDAwMDANCkNhbGwgVHJhY2U6IFs8YzAx > Yjg2ODU+XSBbPGMwMWI3NmQ0Pl0gWzxjMDIyNzlmYj5dIFs8YzAyMDJmYTQ+ > XSBbPGMwMjAzMDgwPl0gWzxjMDFkZWZjYz5dIFs8YzAyMjdmYmU+XQ0KICAg > ICAgIFs8YzAyMjQwOTg+XSBbPGMwMTc5YzE4Pl0gWzxjMDJhZTlmMj5dIFs8 > YzAxNzZkYzc+XSBbPGMwMTc2NDczPl0gWzxjMDJkYjhmOD5dIFs8YzAxNzYy > NDE+XSBbPGMwMTA3NDRmPl0NCkNvZGU6IDBmIDBiIDgzIGM0IDBjIDY4IDAw > IDEwIDAwIDAwIDBmIGI3IDQ2IDI4IDUwIDUzIGU4IDRiIDc0IGY3DQoNCj4+ > RUlQOyBjMDFiODE3MCA8aG9va19idWZmZXJzX3RvX3BhZ2VfZGVsYXkrMjQv > NjQ+ICAgPD09PT09DQpUcmFjZTsgYzAxYjg2ODUgPF9fcGJfYmxvY2tfY29t > bWl0X3dyaXRlX2FzeW5jKzQ1LzRjPg0KVHJhY2U7IGMwMWI3NmQ0IDxwYWdl > YnVmX2lvemVybytmMC8xNmM+DQpUcmFjZTsgYzAyMjc5ZmIgPHhmc196ZXJv > X2VvZiszMWIvNWQ0Pg0KVHJhY2U7IGMwMjAyZmE0IDx4ZnNfaWxvY2srMC8x > OD4NClRyYWNlOyBjMDIwMzA4MCA8eGZzX2l1bmxvY2srMC82OD4NClRyYWNl > OyBjMDFkZWZjYyA8eGZzX2JtYXBpKzAvMTJkOD4NClRyYWNlOyBjMDIyN2Zi > ZSA8eGZzX3dyaXRlKzMwYS82NjA+DQpUcmFjZTsgYzAyMjQwOTggPGxpbnZm > c193cml0ZSsxMTQvMTQwPg0KVHJhY2U7IGMwMTc5YzE4IDxuZnNkX3dyaXRl > KzE0MC8yYTg+DQpUcmFjZTsgYzAyYWU5ZjIgPG5mX2hvb2tfc2xvdytjYS8x > MGM+DQpUcmFjZTsgYzAxNzZkYzcgPG5mc2RfcHJvY193cml0ZStjNy9kMD4N > ClRyYWNlOyBjMDE3NjQ3MyA8bmZzZF9kaXNwYXRjaCtjYi8xNjg+DQpUcmFj > ZTsgYzAyZGI4ZjggPHN2Y19wcm9jZXNzKzJhYy81NDQ+DQpUcmFjZTsgYzAx > NzYyNDEgPG5mc2QrMTkxLzJmOD4NClRyYWNlOyBjMDEwNzQ0ZiA8a2VybmVs > X3RocmVhZCsyMy8zMD4NCkNvZGU7ICBjMDFiODE3MCA8aG9va19idWZmZXJz > X3RvX3BhZ2VfZGVsYXkrMjQvNjQ+DQowMDAwMDAwMCA8X0VJUD46DQpDb2Rl > OyAgYzAxYjgxNzAgPGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzI0LzY0 > PiAgIDw9PT09PQ0KICAgMDogICAwZiAwYiAgICAgICAgICAgICAgICAgICAg > IHVkMmEgICAgICA8PT09PT0NCkNvZGU7ICBjMDFiODE3MiA8aG9va19idWZm > ZXJzX3RvX3BhZ2VfZGVsYXkrMjYvNjQ+DQogICAyOiAgIDgzIGM0IDBjICAg > ICAgICAgICAgICAgICAgYWRkICAgICQweGMsJWVzcA0KQ29kZTsgIGMwMWI4 > MTc1IDxob29rX2J1ZmZlcnNfdG9fcGFnZV9kZWxheSsyOS82ND4NCiAgIDU6 > ICAgNjggMDAgMTAgMDAgMDAgICAgICAgICAgICBwdXNoICAgJDB4MTAwMA0K > Q29kZTsgIGMwMWI4MTdhIDxob29rX2J1ZmZlcnNfdG9fcGFnZV9kZWxheSsy > ZS82ND4NCiAgIGE6ICAgMGYgYjcgNDYgMjggICAgICAgICAgICAgICBtb3Z6 > d2wgMHgyOCglZXNpKSwlZWF4DQpDb2RlOyAgYzAxYjgxN2UgPGhvb2tfYnVm > ZmVyc190b19wYWdlX2RlbGF5KzMyLzY0Pg0KICAgZTogICA1MCAgICAgICAg > ICAgICAgICAgICAgICAgIHB1c2ggICAlZWF4DQpDb2RlOyAgYzAxYjgxN2Yg > PGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzMzLzY0Pg0KICAgZjogICA1 > MyAgICAgICAgICAgICAgICAgICAgICAgIHB1c2ggICAlZWJ4DQpDb2RlOyAg > YzAxYjgxODAgPGhvb2tfYnVmZmVyc190b19wYWdlX2RlbGF5KzM0LzY0Pg0K > ICAxMDogICBlOCA0YiA3NCBmNyAwMCAgICAgICAgICAgIGNhbGwgICBmNzc0 > NjAgPF9FSVArMHhmNzc0NjA+IGMxMTJmNWQwIDxfZW5kK2Q0NDFmYy80NDM4 > YzJjPg0KDQoNCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3Qg > YmUgcmVsaWFibGUuDQo= > ---1702689938-1339662091-986371775=:5540-- From owner-linux-xfs@oss.sgi.com Wed Apr 4 07:36:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34EaKf19400 for linux-xfs-outgoing; Wed, 4 Apr 2001 07:36:20 -0700 Received: from ssadler.phy.bnl.gov (ssadler.phy.bnl.gov [130.199.23.57]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34EaJM19397 for ; Wed, 4 Apr 2001 07:36:19 -0700 Received: from bnl.gov (localhost.localdomain [127.0.0.1]) by ssadler.phy.bnl.gov (8.11.2/8.11.2) with ESMTP id f34Ea7o10744; Wed, 4 Apr 2001 10:36:07 -0400 Message-ID: <3ACB3157.7F5A0CB4@bnl.gov> Date: Wed, 04 Apr 2001 10:36:07 -0400 From: Stephen Adler Organization: Brookhaven National Laboratory X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-0.1.25smp i686) X-Accept-Language: en MIME-Version: 1.0 To: wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: XFS heaven Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm in XFS heaven!!!! I've just built a 280Gig xfs file system, dumped 100 gigs of mirror content on it (linux distributions etc.) hit the reset button on the system and watch it come back with a working 280gig file system in less than 5 seconds. (the time the OS took to mount the xfs file system.) WOW! the disk writing benchmarks scale very nicly with ext2 (i.e. ext2 and xfs wrote data to the disk system at about the same data rate.) So, can someone please get this xfs file system over to Linus! I would really like to see this file system be part of the next rawhide update. Steve. From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:11:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FBKG20518 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:11:20 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FBIM20511 for ; Wed, 4 Apr 2001 08:11:19 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id LAA22602; Wed, 4 Apr 2001 11:05:12 -0400 Message-ID: <3ACB3BD7.45279DCA@ieee.org> Date: Wed, 04 Apr 2001 11:20:55 -0400 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-0.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Adler CC: wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat References: <3ACB3157.7F5A0CB4@bnl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Re: XFS heaven Remember: Linus != RedHat Stephen Adler wrote: > So, can someone please get this xfs file system over to > Linus! I would really like to see this file system be > part of the next rawhide update. AFAIK, Linus has nothing to do with RedHat's choice of JFS. I used Ext3 on kernel 2.2 (since mid last-year), c/o VALinux's kernels. Unfortunately Tweedie will be a little while on getting Ext3 ported to 2.4 (Tweedie should feel free to correct me here if I am wrong). As such, I've begun adopting XFS on my systems for kernel 2.4. ReiserFS is *NOT* an option for me since I run _production_ NFS servers (we 90% UNIX-app based, not just servers! And yes, I know about the patches). In either case, Ext3 or XFS doesn't have to be part of the "official kernel tree" to be in a RedHat kernel. In fact, RedHat has taken a number of 2.2 backports from 2.4 and incorporated them into their kernels. IMHO, XFS _should_ be one of these (on Rawhide). But that's just my opinion. RedHat has their testing/review methodology and I will leave it to them to decide. Until then, the XFS project keeps their CVS tree near-current with the latest kernel and some patches, and periodically produces RPMs and an installer. It's up to RedHat to get involved from there. -- TheBS P.S. According to a recent article on the 2.5 developer's conference, Steve Lord of SGI made a presentation on adopting some of the XFS components for the Linux VFS layer (so all filesystems would benefit). XFS offers full, production ACL support as well as another key details that the VFS could benefit from. Unlike IBM's JFS, SGI's XFS for Linux is GPL (JFS is IPL) so the kernel can benefit directly without license issue. -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ******************************************************** "Linux will do for applications what the Internet did to networks" -- Sam Palmisano, IBM Chief Operating Officer From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:22:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FMfU21105 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:22:41 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FMeM21101 for ; Wed, 4 Apr 2001 08:22:40 -0700 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id RAA29473; Wed, 4 Apr 2001 17:21:15 +0200 Date: Wed, 4 Apr 2001 17:21:15 +0200 From: Christoph Hellwig To: b.j.smith@ieee.org, thebs@theseus.com Cc: Stephen Adler , wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat Message-ID: <20010404172115.A28547@caldera.de> References: <3ACB3157.7F5A0CB4@bnl.gov> <3ACB3BD7.45279DCA@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3ACB3BD7.45279DCA@ieee.org>; from b.j.smith@ieee.org on Wed, Apr 04, 2001 at 11:20:55AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 11:20:55AM -0400, Bryan J. Smith wrote: > Unlike IBM's > JFS, SGI's XFS for Linux is GPL (JFS is IPL) so the kernel can > benefit directly without license issue. JFS is also GPL. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:25:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FPeX21200 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:25:40 -0700 Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FPdM21197 for ; Wed, 4 Apr 2001 08:25:40 -0700 Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192]) by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id LAA22734; Wed, 4 Apr 2001 11:19:08 -0400 Message-ID: <3ACB3F1C.1D7E9346@ieee.org> Date: Wed, 04 Apr 2001 11:34:52 -0400 From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org, thebs@theseus.com Organization: SmithConcepts/Personal X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-0.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: thebs@theseus.com, Stephen Adler , wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat References: <3ACB3157.7F5A0CB4@bnl.gov> <3ACB3BD7.45279DCA@ieee.org> <20010404172115.A28547@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: > JFS is also GPL. I stand corrected then. I read the Linux Gazette article from mid-last year that said IPL (I thought?). -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ******************************************************** "Linux will do for applications what the Internet did to networks" -- Sam Palmisano, IBM Chief Operating Officer From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:28:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FSUx21277 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:28:30 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [207.8.143.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FSTM21274 for ; Wed, 4 Apr 2001 08:28:29 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id E4CA0BC20; Wed, 4 Apr 2001 11:28:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id D67FF3F5C; Wed, 4 Apr 2001 11:28:26 -0400 (EDT) Date: Wed, 4 Apr 2001 11:28:26 -0400 (EDT) From: Mike Burger To: , Cc: Stephen Adler , , Subject: Re: XFS heaven Remember: Linus != RedHat In-Reply-To: <3ACB3BD7.45279DCA@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't think it matters, really, that RedHat may or may not add it, if it's not a part of the official kernel tree. I think Stephen's point was that he'd like to see it wind up in the official kernel tree...If it winds up there, chances are pretty good that it would also wind up in a Redhat distributed kernel. And to Stephen, I would add that, from what I've been reading, XFS isn't necessarily considered "ready for prime time" (someone on the development team correct me me if my inference is incorrect). Having said that, I think it would probably be best to hve the development team be 100% confident that they've got everything worked out, before it is submitted to the kernel development team for inclusion in the "official" kernel. On Wed, 4 Apr 2001, Bryan J. Smith wrote: > Re: XFS heaven Remember: Linus != RedHat > > Stephen Adler wrote: > > So, can someone please get this xfs file system over to > > Linus! I would really like to see this file system be > > part of the next rawhide update. > > AFAIK, Linus has nothing to do with RedHat's choice of JFS. > > I used Ext3 on kernel 2.2 (since mid last-year), c/o VALinux's > kernels. Unfortunately Tweedie will be a little while on getting > Ext3 ported to 2.4 (Tweedie should feel free to correct me here if I > am wrong). As such, I've begun adopting XFS on my systems for > kernel 2.4. ReiserFS is *NOT* an option for me since I run > _production_ NFS servers (we 90% UNIX-app based, not just servers! > And yes, I know about the patches). > > In either case, Ext3 or XFS doesn't have to be part of the "official > kernel tree" to be in a RedHat kernel. In fact, RedHat has taken a > number of 2.2 backports from 2.4 and incorporated them into their > kernels. IMHO, XFS _should_ be one of these (on Rawhide). But > that's just my opinion. RedHat has their testing/review methodology > and I will leave it to them to decide. > > Until then, the XFS project keeps their CVS tree near-current with > the latest kernel and some patches, and periodically produces RPMs > and an installer. It's up to RedHat to get involved from there. > > -- TheBS > > P.S. According to a recent article on the 2.5 developer's > conference, Steve Lord of SGI made a presentation on adopting some > of the XFS components for the Linux VFS layer (so all filesystems > would benefit). XFS offers full, production ACL support as well as > another key details that the VFS could benefit from. Unlike IBM's > JFS, SGI's XFS for Linux is GPL (JFS is IPL) so the kernel can > benefit directly without license issue. > > From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:34:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FY5G21442 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:34:05 -0700 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FY3M21439 for ; Wed, 4 Apr 2001 08:34:04 -0700 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id RAA00434; Wed, 4 Apr 2001 17:32:43 +0200 Date: Wed, 4 Apr 2001 17:32:43 +0200 From: Christoph Hellwig To: b.j.smith@ieee.org, thebs@theseus.com Cc: Christoph Hellwig , Stephen Adler , wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat Message-ID: <20010404173243.A32696@caldera.de> References: <3ACB3157.7F5A0CB4@bnl.gov> <3ACB3BD7.45279DCA@ieee.org> <20010404172115.A28547@caldera.de> <3ACB3F1C.1D7E9346@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3ACB3F1C.1D7E9346@ieee.org>; from b.j.smith@ieee.org on Wed, Apr 04, 2001 at 11:34:52AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 11:34:52AM -0400, Bryan J. Smith wrote: > Christoph Hellwig wrote: > > JFS is also GPL. > > I stand corrected then. I read the Linux Gazette article from > mid-last year that said IPL (I thought?). Damn, is is so difficult to look at the source? Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Apr 4 08:47:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34FlC621978 for linux-xfs-outgoing; Wed, 4 Apr 2001 08:47:12 -0700 Received: from ssadler.phy.bnl.gov (ssadler.phy.bnl.gov [130.199.23.57]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34FlBM21975 for ; Wed, 4 Apr 2001 08:47:11 -0700 Received: from bnl.gov (localhost.localdomain [127.0.0.1]) by ssadler.phy.bnl.gov (8.11.2/8.11.2) with ESMTP id f34FkKo11511; Wed, 4 Apr 2001 11:46:20 -0400 Message-ID: <3ACB41CC.9C905860@bnl.gov> Date: Wed, 04 Apr 2001 11:46:20 -0400 From: Stephen Adler Organization: Brookhaven National Laboratory X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-0.1.25smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger CC: b.j.smith@ieee.org, thebs@theseus.com, wolverine-list@redhat.com, linux-xfs@oss.sgi.com, torvals@transmeta.com Subject: Re: XFS heaven Remember: Linus != RedHat References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > And to Stephen, I would add that, from what I've been reading, XFS isn't > necessarily considered "ready for prime time" (someone on the development > team correct me me if my inference is incorrect). Having said that, I > think it would probably be best to hve the development team be 100% > confident that they've got everything worked out, before it is submitted > to the kernel development team for inclusion in the "official" kernel. > I disagree, may new features which make it into the kernel are not 100% ready for prime. As a matter of fact, the only way you can make something 100% ready from prime is to get everyone to use it on the internet and then you will find all the bugs. I think reiserfs is a very good example. its in the official kernel tree even though there are known corruptability issues. Redhat then puts it into rawhide to let us bleeding edgers kick its tires by building large file systems with it. Once a piece of software reaches a pleateau of stability within the developers circles, you have to let it out for the rest of us to use. As from what I read on the mailing lists, xfs has reached a stability pleateau on par with reiserfs and thus should be let into the kernel tree. OK, off my soap box. Steve. From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:34:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GYjJ23673 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:34:45 -0700 Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GYiM23670 for ; Wed, 4 Apr 2001 09:34:44 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id MAA30883 for ; Wed, 4 Apr 2001 12:34:42 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 4 Apr 2001 12:34:42 -0400 (EDT) From: Joshua Baker-LePain X-Sender: To: Linux xfs mailing list Subject: Which compiler for xfs tools Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On RH7.0, I know to use kgcc for the kernel itself. But what is the recommended compiler when building the stuff under linux-2.4-xfs/cmd? And, if it's kgcc, where is the quickest and easiest place to fix that and still be able to build rpms? Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:34:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GYpZ23686 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:34:51 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GYoM23683 for ; Wed, 4 Apr 2001 09:34:51 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02923 for ; Wed, 4 Apr 2001 09:34:49 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA21635 for ; Wed, 4 Apr 2001 11:33:33 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f34GLw828367 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 12:21:58 -0400 Date: Wed, 4 Apr 2001 12:21:58 -0400 From: Russell Cattelan Message-Id: <200104041621.f34GLw828367@gibble.americas.sgi.com> Subject: TAKE - Merge of kiobuf unmerge Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Back out kiobuf based I/O path Date: Wed Apr 4 09:31:49 PDT 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0 Author: lord Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:91559a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0 Modid: 2.4.x-xfs-r1.0:slinx:91559a linux/kernel/ksyms.c - 1.82 linux/include/linux/major.h - 1.25 linux/include/linux/genhd.h - 1.11 linux/include/linux/fs.h - 1.86 linux/include/linux/blkdev.h - 1.29 linux/fs/buffer.c - 1.59 linux/drivers/scsi/sd.c - 1.34 linux/drivers/block/rd.c - 1.28 linux/drivers/block/loop.c - 1.29 linux/drivers/block/ll_rw_blk.c - 1.64 linux/include/linux/ide.h - 1.28 linux/fs/iobuf.c - 1.16 linux/drivers/char/raw.c - 1.14 linux/include/linux/iobuf.h - 1.11 linux/fs/partitions/check.c - 1.22 linux/drivers/scsi/scsi_merge.c - 1.27 linux/drivers/scsi/scsi_lib.c - 1.28 linux/drivers/ide/ide.c - 1.19 linux/drivers/ide/ide-dma.c - 1.10 linux/drivers/ide/ide-disk.c - 1.13 linux/drivers/block/elevator.c - 1.8 linux/fs/xfs/linux/xfs_super.c - 1.113 linux/kdb/modules/kdbm_pg.c - 1.31 linux/fs/pagebuf/page_buf.c - 1.68 linux/drivers/md/raid1.c - 1.7 linux/drivers/md/raid5.c - 1.12 - Merge of 2.4.x-xfs:slinx:91559a by cattelan. From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:35:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GZTc23707 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:35:29 -0700 Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [207.8.143.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GZTM23704 for ; Wed, 4 Apr 2001 09:35:29 -0700 Received: by linux.compucomis.net (Postfix, from userid 501) id 2409CBC20; Wed, 4 Apr 2001 12:35:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by linux.compucomis.net (Postfix) with ESMTP id EDA8B3F5A; Wed, 4 Apr 2001 12:35:27 -0400 (EDT) Date: Wed, 4 Apr 2001 12:35:27 -0400 (EDT) From: Mike Burger To: Stephen Adler Cc: , , , , Subject: Re: XFS heaven Remember: Linus != RedHat In-Reply-To: <3ACB41CC.9C905860@bnl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was thinking of any chance of stability, with regard to the file system, itself. Having just lived through an ext2 meltdown on my primary server (I'm still picking up the pieces), I'm speaking from experience. On Wed, 4 Apr 2001, Stephen Adler wrote: > > > > And to Stephen, I would add that, from what I've been reading, XFS isn't > > necessarily considered "ready for prime time" (someone on the development > > team correct me me if my inference is incorrect). Having said that, I > > think it would probably be best to hve the development team be 100% > > confident that they've got everything worked out, before it is submitted > > to the kernel development team for inclusion in the "official" kernel. > > > > I disagree, may new features which make it into the kernel are not 100% > ready for prime. As a matter of fact, the only way you can make > something > 100% ready from prime is to get everyone to use it on the internet and > then > you will find all the bugs. I think reiserfs is a very good example. its > in the official kernel tree even though there are known corruptability > issues. > Redhat then puts it into rawhide to let us bleeding edgers kick its > tires > by building large file systems with it. Once a piece of software reaches > a pleateau of stability within the developers circles, you have to let > it out for the rest of us to use. As from what I read on the mailing > lists, > xfs has reached a stability pleateau on par with reiserfs and thus > should > be let into the kernel tree. > > OK, off my soap box. > > Steve. > From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:49:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GnrN24164 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:49:53 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GnqM24159 for ; Wed, 4 Apr 2001 09:49:52 -0700 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08715 for ; Wed, 4 Apr 2001 09:49:51 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA71996 for ; Wed, 4 Apr 2001 11:48:35 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f34Gb0k31231 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 12:37:00 -0400 Date: Wed, 4 Apr 2001 12:37:00 -0400 From: Russell Cattelan Message-Id: <200104041637.f34Gb0k31231@gibble.americas.sgi.com> Subject: TAKE - Removed BH_End_io Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Apr 4 09:46:50 PDT 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0 Author: lord Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:91406a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0 Modid: 2.4.x-xfs-r1.0:slinx:91406a linux/include/linux/fs.h - 1.87 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Remove BH_End_io flag. linux/drivers/block/ll_rw_blk.c - 1.65 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Remove BH_End_io check from ll_rw_block, we do not need it anymore. linux/kdb/modules/kdbm_pg.c - 1.32 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Fixup buffer head flag printing code. linux/fs/pagebuf/page_buf.c - 1.69 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Cleanup buffer flag setting linux/fs/pagebuf/page_buf_io.c - 1.71 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Cleanup end_io handling for buffer heads, we no longer need as many special purpose handlers, or the BH_end_io flag. linux/drivers/md/raid5.c - 1.13 - Merge of 2.4.x-xfs:slinx:91406a by cattelan. Remove BH_End_io checks - the flag is gone From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:56:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GuQY24384 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:56:26 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GuPM24379 for ; Wed, 4 Apr 2001 09:56:25 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id EAED11E107; Wed, 4 Apr 2001 18:56:23 +0200 (MEST) Date: Wed, 4 Apr 2001 18:56:12 +0200 From: Andi Kleen To: Stephen Adler Cc: Mike Burger , b.j.smith@ieee.org, thebs@theseus.com, wolverine-list@redhat.com, linux-xfs@oss.sgi.com, torvals@transmeta.com Subject: Re: XFS heaven Remember: Linus != RedHat Message-ID: <20010404185612.A2444@gruyere.muc.suse.de> References: <3ACB41CC.9C905860@bnl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACB41CC.9C905860@bnl.gov>; from adler@bnl.gov on Wed, Apr 04, 2001 at 11:46:20AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 11:46:20AM -0400, Stephen Adler wrote: > you will find all the bugs. I think reiserfs is a very good example. its > in the official kernel tree even though there are known corruptability > issues. [off-topic, but needs correction] There are no known corruption issues in current reiserfs AFAIK, but generic 2.4 has some not depending on the file system. -Andi From owner-linux-xfs@oss.sgi.com Wed Apr 4 09:57:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34GvNb24415 for linux-xfs-outgoing; Wed, 4 Apr 2001 09:57:23 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34GvMM24412 for ; Wed, 4 Apr 2001 09:57:22 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 27A3F1E107; Wed, 4 Apr 2001 18:57:21 +0200 (MEST) Date: Wed, 4 Apr 2001 18:57:20 +0200 From: Andi Kleen To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Merge of kiobuf unmerge Message-ID: <20010404185720.B2444@gruyere.muc.suse.de> References: <200104041621.f34GLw828367@gibble.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: <200104041621.f34GLw828367@gibble.americas.sgi.com>; from cattelan@sgi.com on Wed, Apr 04, 2001 at 12:21:58PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 12:21:58PM -0400, Russell Cattelan wrote: > Back out kiobuf based I/O path Pity :-(( Hopefully there will be a worthy replacement found in 2.5. -Andi From owner-linux-xfs@oss.sgi.com Wed Apr 4 10:01:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34H1C324553 for linux-xfs-outgoing; Wed, 4 Apr 2001 10:01:12 -0700 Received: from thor.theseus.com (south.orl-pub.theseus.com [12.108.42.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34H1CM24550 for ; Wed, 4 Apr 2001 10:01:12 -0700 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA02326; Wed, 4 Apr 2001 13:06:23 -0400 Message-ID: <3ACB53AB.87FAA57D@theseus.com> Date: Wed, 04 Apr 2001 13:02:35 -0400 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: b.j.smith@ieee.org, Stephen Adler , wolverine-list@redhat.com, linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat References: <3ACB3157.7F5A0CB4@bnl.gov> <3ACB3BD7.45279DCA@ieee.org> <20010404172115.A28547@caldera.de> <3ACB3F1C.1D7E9346@ieee.org> <20010404173243.A32696@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: > Damn, is is so difficult to look at the source? I haven't messed with JFS at all. As such, I will no longer comment on it. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Apr 4 10:02:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34H2Tt24595 for linux-xfs-outgoing; Wed, 4 Apr 2001 10:02:29 -0700 Received: from thor.theseus.com (south.orl-pub.theseus.com [12.108.42.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34H2SM24592 for ; Wed, 4 Apr 2001 10:02:29 -0700 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA02426; Wed, 4 Apr 2001 13:07:53 -0400 Message-ID: <3ACB5404.2AA2EF48@theseus.com> Date: Wed, 04 Apr 2001 13:04:04 -0400 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Baker-LePain CC: Linux xfs mailing list Subject: Re: Which compiler for xfs tools References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joshua Baker-LePain wrote: > On RH7.0, I know to use kgcc for the kernel itself. > But what is the recommended compiler when building > the stuff under linux-2.4-xfs/cmd? And, if it's > kgcc, where is the quickest and easiest place to fix > that and still be able to build rpms? FYI, I think there was a previous thread on the "kgcc" issue where users of non-RedHat RPM distros took offense in the default packaging. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Apr 4 10:19:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34HJ2S24968 for linux-xfs-outgoing; Wed, 4 Apr 2001 10:19:02 -0700 Received: from thor.theseus.com (south.orl-pub.theseus.com [12.108.42.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34HJ1M24965 for ; Wed, 4 Apr 2001 10:19:01 -0700 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA03343; Wed, 4 Apr 2001 13:24:22 -0400 Message-ID: <3ACB57E0.9EF290B2@theseus.com> Date: Wed, 04 Apr 2001 13:20:32 -0400 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Adler CC: Mike Burger , b.j.smith@ieee.org, wolverine-list@redhat.com, linux-xfs@oss.sgi.com, torvals@transmeta.com Subject: Re: XFS heaven Remember: Linus != RedHat References: <3ACB41CC.9C905860@bnl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Adler wrote: > I disagree, may new features which make it into the kernel > are not 100% ready for prime. As a sysadmin, I have seen this with 2.4 in the stock, RedHat and XFS kernels. There are many things still incomplete and/or buggy with 2.4. I don't know how many times I've seen bugs reported on this list that end up being general kernel 2.4 issues. This is to be "expected" with 2.4's relative "newness" and as more and more "diversity" in systems using 2.4 find these issues. XFS is already proven on the Irix platform. And the structure is not changing (unlike ReiserFS, although I heard Linus made Reiser stick with a fixed structure before 2.4 inclusion?). IMHO, XFS is as ready for "production use" as ReiserFS -- more so if you consider the fact that the kernel must be patched so ReiserFS can work with kNFSd. [ Side note: I would love to see Ext3 put into the stock 2.2 tree as it, in v1/full-data-journaling mode, has been more stable than ReiserFS for me. I have been running with Ext3 on high-activity, production CVS/SMB/NFS _servers_ for almost a year now. ] Now being a non-developer, anyone should _rebuke_me_ if I am incorrect anywhere here. I'm just speaking from end-user/sysadmin use. > As a matter of fact, the only way you can make something > 100% ready from prime is to get everyone to use it on the > internet and then you will find all the bugs. Again, IMHO as a non-developer, XFS is at the point where it should be included in the stock kernel -- at least as much as ReiserFS should be. This *MAY* be a "flawed" viewpoint, and both should NOT be in the kernel and I'm surprised ReiserFS went in on 2.4.1 -- but I'm *NOT* going to "second guess" others who obviously know more than me about the code anymore than I have ;-PPP. But I see that XFS patches against the stock kernel well, the XFS developers are maintaining an up-to-date kernel tree in CVS themselves (because it patches fairly easily), and offers an existing implementation that works on other platforms (unlike ReiserFS). > I think reiserfs is a very good example. its in the official kernel > tree even though there are known corruptability issues. I don't know if I would go that far, but it does have some kNFSd issues (if not just interoperability, but performance). > Redhat then puts it into rawhide to let us bleeding edgers kick its > tires by building large file systems with it. Well, if it's in the stock kernel, RedHat's not going to yank it out. Frankly, I'd like to see Tweedie's knowledge put to use on XFS, but I'm not his boss, nor do I know what he's up to. ;-PPP Ext3 on 2.2 is great, I use it liberally, and I'm sure Tweedie would love to get Ext3 out on 2.4 ASAP. But maybe it's time we look at XFS as "our future" for Linux? Disclaimer: Just my $0.02 on that -- feel free to *SMACK* this "non-developer" silly. @-P > Once a piece of software reaches a pleateau of stability within > the developers circles, you have to let it out for the rest of > us to use. As from what I read on the mailing lists, > xfs has reached a stability pleateau on par with reiserfs and thus > should be let into the kernel tree. That was my point. Although if ReiserFS isn't "really stable enough" to be in the kernel tree, what good does it do to put XFS in as well (two "wrongs" don't make a "right," eh)? I don't know the circumstances, but I felt like ReiserFS' inclusion in 2.4.1 was more political/demand than technical. But I'm not going to comment on that anymore since I'm probably making it in great ignorance. > OK, off my soap box. Yeah, me too. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Apr 4 10:25:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34HPCU25229 for linux-xfs-outgoing; Wed, 4 Apr 2001 10:25:12 -0700 Received: from thor.theseus.com (south.orl-pub.theseus.com [12.108.42.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34HPCM25226 for ; Wed, 4 Apr 2001 10:25:12 -0700 Received: from theseus.com (IDENT:thebs@fugitive.theseus.com [192.168.0.242]) by thor.theseus.com (8.9.3/8.9.3) with ESMTP id NAA03719; Wed, 4 Apr 2001 13:30:32 -0400 Message-ID: <3ACB5953.565D0978@theseus.com> Date: Wed, 04 Apr 2001 13:26:43 -0400 From: Bryan-TheBS-Smith Reply-To: thebs@theseus.com, b.j.smith@ieee.org Organization: (Personal) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-0.17-FUGITIVE i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger CC: Stephen Adler , b.j.smith@ieee.org, wolverine-list@redhat.com, linux-xfs@oss.sgi.com, torvals@transmeta.com Subject: Re: XFS heaven Remember: Linus != RedHat References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > I was thinking of any chance of stability, with regard to the file > system, itself. Having just lived through an ext2 meltdown on my > primary server (I'm still picking up the pieces), I'm speaking > from experience. Really? Hmmm, been using Ext2 on production systems since 1995, Ext3 since mid-2000. The most I've ever had was a fsck that output MAXINT length filesizes that had to be cleared with "debugfs" -- but that was due to a _physical_disk_error_. My volume stayed intact with exception of ~100 files / ~2MB of data As an original NT 3.1 beta tester and NT admin through early 1999 (8 years experience), I canNOT say the same about NTFS. A physical disk error was usually a major pain and it was recommended you get all the data off you could (ha!) and reformat. In addition, I had 2 non-physical error-related NTFS _total_corruptions_ because of an _incorrect_journal_read_. I.e., I find NTFS is a little "too aggressive" in going to the journal whereas filesystems like Ext3 will _always_ drop down to a full "Ext2 fsck" if it detects anything remotely incorrect. I haven't worked with XFS long enough to see it take any issue after an improper shutdown, log/journal read. -- TheBS -- Bryan "TheBS" Smith chat:thebs413 @AOL/MSN/Yahoo Engineer mailto:b.j.smith@ieee.org,thebs@theseus.com ********************************************************* "Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver From owner-linux-xfs@oss.sgi.com Wed Apr 4 10:33:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34HXbE25609 for linux-xfs-outgoing; Wed, 4 Apr 2001 10:33:37 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34HXaM25605 for ; Wed, 4 Apr 2001 10:33:36 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA02016 for ; Wed, 4 Apr 2001 10:32:21 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1358209; Wed, 4 Apr 2001 12:32:14 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA33462; Wed, 4 Apr 2001 12:32:14 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34HYie14367; Wed, 4 Apr 2001 12:34:44 -0500 Message-Id: <200104041734.f34HYie14367@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Joshua Baker-LePain cc: Linux xfs mailing list Subject: Re: Which compiler for xfs tools In-Reply-To: Message from Joshua Baker-LePain of "Wed, 04 Apr 2001 12:34:42 EDT." Date: Wed, 04 Apr 2001 12:34:44 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On RH7.0, I know to use kgcc for the kernel itself. But what is the > recommended compiler when building the stuff under linux-2.4-xfs/cmd? > And, if it's kgcc, where is the quickest and easiest place to fix that and > still be able to build rpms? > > Thanks. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University I have not seen any compiler issues with user space - we generally use whatever gcc happens to be, and I am running RedHat 7.0 with the latest released 2.96. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:20:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34IKIM27395 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:20:18 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IKIM27392 for ; Wed, 4 Apr 2001 11:20:18 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA09435 for ; Wed, 4 Apr 2001 11:19:02 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA24988; Wed, 4 Apr 2001 13:19:01 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f34I7Qb32101; Wed, 4 Apr 2001 14:07:26 -0400 Message-ID: <3ACB62DC.B0452F0F@thebarn.com> Date: Wed, 04 Apr 2001 14:07:24 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: TAKE - Merge of kiobuf unmerge References: <200104041621.f34GLw828367@gibble.americas.sgi.com> <20010404185720.B2444@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen wrote: > On Wed, Apr 04, 2001 at 12:21:58PM -0400, Russell Cattelan wrote: > > Back out kiobuf based I/O path > > Pity :-(( Hopefully there will be a worthy replacement found in 2.5. Yes agreed... Given the controversy around kiobuf's right now, we felt it best to disassociate the release of XFS from them. A patch been archived in the source tree so that we may revive this work at the appropriate time. > > > -Andi -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:22:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34IMKN27461 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:22:20 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IMJM27457 for ; Wed, 4 Apr 2001 11:22:19 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA09763 for ; Wed, 4 Apr 2001 11:21:04 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA07361 for ; Wed, 4 Apr 2001 13:21:03 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f34I9Sw32169 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 14:09:28 -0400 Date: Wed, 4 Apr 2001 14:09:28 -0400 From: Russell Cattelan Message-Id: <200104041809.f34I9Sw32169@gibble.americas.sgi.com> Subject: TAKE - kiobuf patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not entirely nessesary to merge this over but just to keep stuff in sync. Date: Wed Apr 4 11:18:50 PDT 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0 Author: lord Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:91557a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0 Modid: 2.4.x-xfs-r1.0:slinx:91557a cmd/xfsmisc/kiobuf_io.patch - 1.1 - Merge of 2.4.x-xfs:slinx:91557a by cattelan. The kiobuf I/O patch - apply this to get the kiobuf I/O path back into the kernel. cmd/xfsmisc/README - 1.2 - Merge of 2.4.x-xfs:slinx:91557a by cattelan. Added info on kiobuf_io.patch From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:25:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34IPB827547 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:25:11 -0700 Received: from eem12.resnet.cornell.edu (eem12.resnet.cornell.edu [128.253.247.185]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IPAM27544 for ; Wed, 4 Apr 2001 11:25:10 -0700 Received: (from eem12@localhost) by eem12.resnet.cornell.edu (8.11.2/8.11.2) id f34IPHb01352 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 14:25:17 -0400 Date: Wed, 4 Apr 2001 14:25:17 -0400 From: Ed McKenzie To: linux-xfs@oss.sgi.com Subject: XFS volume labels Message-ID: <20010404142517.B1267@eem12.resnet.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, I can set XFS volume labels using xfs_admin, but it seems the kernel can't mount-by-label (which is how RH7 does things.) Is this a TODO item? If I do a clean install on another machine using the prerelease CD, will I have a functional system? :) (I've also noticed that some of my ext2 disks no longer mount-by-label, even though e2label shows the expected value.) Thanks in advance, ed From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:29:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34ITT027659 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:29:29 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34ITSM27656 for ; Wed, 4 Apr 2001 11:29:28 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA10644 for ; Wed, 4 Apr 2001 11:28:13 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA14359; Wed, 4 Apr 2001 13:28:12 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f34IGab32193; Wed, 4 Apr 2001 14:16:36 -0400 Message-ID: <3ACB6504.5C4A3F91@thebarn.com> Date: Wed, 04 Apr 2001 14:16:36 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Ajay Shekhawat CC: linux-xfs@oss.sgi.com Subject: Re: XFS 2.4.3 patch References: <3AC6733F.3B62AC5E@thebarn.com> <20010401145556.U16131@zaurak.cedar.buffalo.edu> <3ACA5148.FC61A9A3@thebarn.com> <20010403195629.T16131@zaurak.cedar.buffalo.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ajay Shekhawat wrote: > On Tue, Apr 03, 2001 at 06:40:09PM -0400, Russell Cattelan wrote: > > We haven't been able to duplicate this panic locally yet. > > Could you let us know what you are using for test machines > > client and server, number of processors in each, kernel version, > > linux distro version, speed of network between the machines. > > Finally what are you doing to "stress" nfs? > > The server is a dual P-II 450MHz machine with an ASUS P2B-DS motherboard > and 256MB memory. It has a 3c905B ethernet card, leading to a Cisco > Cat 5000 switch. This machine is running RedHat Wolverine, with the > kernel upgraded to 2.4.3-XFS (i.e., stock 2.4.3 with the XFS patches). > It has an onboard AIC7890 SCSI controller. > It has 3 Seagate ST34502LW 4GB SCSI disks. One of these disks has been > formatted as XFS, and is exported via NFS. > The server has NFSv3 support enabled, and kernel NFSD. > > The clients are 4 Linux boxes, each running RH6.2 or RH7.0. All have 100bT > ethernet hooked to the Cat 5000. > > All of the clients mount the exported filesystem from the server. This > filesystem contains 1000 files of 3MB each. There is a "file list" > at the top level, which contains a list of all the files including the full > pathname. Looks like a fairly standard configuration. > > > Each of the clients runs a Perl script in a tight loop which does the > following: > - Grabs a random filename from this list > - stat()s and opens that file, and reads the entire contents > - close()s the file This part is what we need to duplicate. can you send us this script? > > > One of the clients (a dual P-III 800MHz box) has a script that also > continuously writes files of size [4K .. 1MB]; it keeps at most 32 files > around, deleting old ones as it creates new ones. > > This test setup looks weird, but it is designed to sort of simulate the > end use that this server is likely to get. > > After about 18 hours or so of usage, the machine gets an oops. In this > time, the clients have each read about 38000 files each. > > Ajay -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:31:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34IVwL27729 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:31:58 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IVuM27726 for ; Wed, 4 Apr 2001 11:31:56 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02762 for ; Wed, 4 Apr 2001 11:42:07 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1365770; Wed, 4 Apr 2001 13:29:37 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA49569; Wed, 4 Apr 2001 13:29:37 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34IW9V01300; Wed, 4 Apr 2001 13:32:09 -0500 Message-Id: <200104041832.f34IW9V01300@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ed McKenzie cc: linux-xfs@oss.sgi.com Subject: Re: XFS volume labels In-Reply-To: Message from Ed McKenzie of "Wed, 04 Apr 2001 14:25:17 EDT." <20010404142517.B1267@eem12.resnet.cornell.edu> Date: Wed, 04 Apr 2001 13:32:09 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Hello all, > > I can set XFS volume labels using xfs_admin, but it seems the kernel > can't mount-by-label (which is how RH7 does things.) Is this a TODO > item? If I do a clean install on another machine using the prerelease > CD, will I have a functional system? :) > > (I've also noticed that some of my ext2 disks no longer > mount-by-label, even though e2label shows the expected value.) > > Thanks in advance, > ed Mount by label is all user space, there is no kernel code involved, beyond reading data out the block device interface to look for the magic numbers. You need a version of the mount command with this support in it for the code to function. I am using mount-2.10m-6 but I have to admit I have not tried a mount by label recently. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:45:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34IjLR28174 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:45:21 -0700 Received: from eem12.resnet.cornell.edu (eem12.resnet.cornell.edu [128.253.247.185]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IjKM28171 for ; Wed, 4 Apr 2001 11:45:20 -0700 Received: (from eem12@localhost) by eem12.resnet.cornell.edu (8.11.2/8.11.2) id f34IjQq01551; Wed, 4 Apr 2001 14:45:26 -0400 Date: Wed, 4 Apr 2001 14:45:25 -0400 From: Ed McKenzie To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: XFS volume labels Message-ID: <20010404144525.C1267@eem12.resnet.cornell.edu> References: <200104041832.f34IW9V01300@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104041832.f34IW9V01300@jen.americas.sgi.com>; from lord@sgi.com on Wed, Apr 04, 2001 at 01:32:09PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 01:32:09PM -0500, Steve Lord wrote: > Mount by label is all user space, there is no kernel code involved, Ah. There was talk on lkml about allowing the kernel to find the root fs by UUID or label, so I assumed all of this was done in the kernel. > beyond reading data out the block device interface to look for the > magic numbers. You need a version of the mount command with this > support in it for the code to function. > > I am using mount-2.10m-6 but I have to admit I have not tried a mount > by label recently. 2.10r-4 from Wolverine here. Looking at the source, it appears XFS label support is already implemented. I'm investigating. -ed From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:46:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34Ikm628270 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:46:48 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34IklM28264 for ; Wed, 4 Apr 2001 11:46:47 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA13506 for ; Wed, 4 Apr 2001 11:45:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1368633; Wed, 4 Apr 2001 13:45:30 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA16533; Wed, 4 Apr 2001 13:45:30 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34Im1C02143; Wed, 4 Apr 2001 13:48:01 -0500 Message-Id: <200104041848.f34Im1C02143@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - Merge of kiobuf unmerge In-Reply-To: Message from Russell Cattelan of "Wed, 04 Apr 2001 14:07:24 EDT." <3ACB62DC.B0452F0F@thebarn.com> Date: Wed, 04 Apr 2001 13:48:01 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Andi Kleen wrote: > > > On Wed, Apr 04, 2001 at 12:21:58PM -0400, Russell Cattelan wrote: > > > Back out kiobuf based I/O path > > > > Pity :-(( Hopefully there will be a worthy replacement found in 2.5. > > Yes agreed... > Given the controversy around kiobuf's right now, we felt it best to > disassociate the release of XFS from them. > > A patch been archived in the source tree so that we may revive this > work > at the appropriate time. > > > > > > > -Andi > I spoke with Stephen Tweedie about this, and he was of the opinion that the final direction would be sufficiently different that the existing code would only be useful as salvage. Other people are free to take the code and do with it what they want of course. We just have to keep kicking Jens until some code emerges ;-) Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 11:55:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34ItRc28797 for linux-xfs-outgoing; Wed, 4 Apr 2001 11:55:27 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34ItQM28793 for ; Wed, 4 Apr 2001 11:55:26 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA02926 for ; Wed, 4 Apr 2001 12:05:40 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1366936; Wed, 4 Apr 2001 13:54:08 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA79535; Wed, 4 Apr 2001 13:54:08 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34IueT02232; Wed, 4 Apr 2001 13:56:40 -0500 Message-Id: <200104041856.f34IueT02232@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Ed McKenzie cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: XFS volume labels In-Reply-To: Message from Ed McKenzie of "Wed, 04 Apr 2001 14:45:25 EDT." <20010404144525.C1267@eem12.resnet.cornell.edu> Date: Wed, 04 Apr 2001 13:56:40 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > On Wed, Apr 04, 2001 at 01:32:09PM -0500, Steve Lord wrote: > > Mount by label is all user space, there is no kernel code involved, > > Ah. There was talk on lkml about allowing the kernel to find the root > fs by UUID or label, so I assumed all of this was done in the kernel. > > > beyond reading data out the block device interface to look for the > > magic numbers. You need a version of the mount command with this > > support in it for the code to function. > > > > I am using mount-2.10m-6 but I have to admit I have not tried a mount > > by label recently. > > 2.10r-4 from Wolverine here. Looking at the source, it appears XFS > label support is already implemented. I'm investigating. It is possible our labeling code got broken, have you tried the uuid version of the mount? You can also use xfs_db directly to dump this stuff out: xfs_db -r /dev/xxxx sb 0 print Steve > > -ed From owner-linux-xfs@oss.sgi.com Wed Apr 4 13:54:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34KsdA31397 for linux-xfs-outgoing; Wed, 4 Apr 2001 13:54:39 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34KscM31394 for ; Wed, 4 Apr 2001 13:54:38 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA02134 for ; Wed, 4 Apr 2001 13:53:23 -0700 (PDT) mail_from (cattelan@gibble.americas.sgi.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA27988 for ; Wed, 4 Apr 2001 15:53:22 -0500 (CDT) Received: (from cattelan@localhost) by gibble.americas.sgi.com (8.11.2/8.11.2) id f34KqLv00861 for linux-xfs@oss.sgi.com; Wed, 4 Apr 2001 16:52:21 -0400 Date: Wed, 4 Apr 2001 16:52:21 -0400 From: Russell Cattelan Message-Id: <200104042052.f34KqLv00861@gibble.americas.sgi.com> Subject: TAKE - XFS Patch pull script Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Apr 4 13:51:52 PDT 2001 Workarea: gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:91724a cmd/xfsmisc/XFSgenPatch.pl - 1.1 - Checking this in for safe keeping. From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:02:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34L2Uo31924 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:02:30 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34L2SM31921 for ; Wed, 4 Apr 2001 14:02:29 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03043 for ; Wed, 4 Apr 2001 14:00:55 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA41127 for ; Wed, 4 Apr 2001 16:00:12 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f34KxCb00909 for ; Wed, 4 Apr 2001 16:59:12 -0400 Message-ID: <3ACB8B1E.F4F5251E@thebarn.com> Date: Wed, 04 Apr 2001 16:59:10 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS -> linux 2.4.2 w/o kiobufs. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A new patch against linux 2.4.2 without the kiobufs has been generated and placed on linux-xfs.sgi.com/oss.sgi.com Functionally this patch is the same as the one dated 04/01/2001 except for the kiobuf support. -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:14:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34LEnR32375 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:14:49 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LEmM32368 for ; Wed, 4 Apr 2001 14:14:48 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 72B791E1DE; Wed, 4 Apr 2001 23:14:47 +0200 (MEST) Date: Wed, 4 Apr 2001 23:14:46 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - Merge of kiobuf unmerge Message-ID: <20010404231446.A5354@gruyere.muc.suse.de> References: <200104041848.f34Im1C02143@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104041848.f34Im1C02143@jen.americas.sgi.com>; from lord@sgi.com on Wed, Apr 04, 2001 at 01:48:01PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 01:48:01PM -0500, Steve Lord wrote: > I spoke with Stephen Tweedie about this, and he was of the opinion that the > final direction would be sufficiently different that the existing code > would only be useful as salvage. Other people are free to take the code and > do with it what they want of course. We just have to keep kicking Jens > until some code emerges ;-) Hopefully there will some agreement on that final direction soon (so far none is in sight as far as I can see) Looks like design by comittee is not working very well here. -Andi From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:23:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34LN5832661 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:23:05 -0700 Received: from colt.wildfirenetwork.com (colt.wildfirenetwork.com [65.100.38.105]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LN5M32658 for ; Wed, 4 Apr 2001 14:23:05 -0700 Received: from sks.wildfirenetwork.com ([192.168.0.35] helo=sks.praesidiumfinancial.com ident=bknotts) by colt.wildfirenetwork.com with esmtp (Exim 3.22 #10) id 14kuk1-0004il-00 for linux-xfs@oss.sgi.com; Wed, 04 Apr 2001 14:23:01 -0700 Message-ID: X-Mailer: XFMail 1.4.7 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 04 Apr 2001 14:23:24 -0700 (PDT) From: Brian Knotts To: linux-xfs@oss.sgi.com Subject: chgrp broken by 2.4.3-cvs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I haven't seen anything about this, so I thought I'd mention it. There seems to be something amiss with groups and the cvs tree as of yesterday. After installing a kernel compiled from yesterday's cvs, I was unable to chgrp any files. Reverting to a previous kernel (2.4.2, also from cvs, from Mar 2) fixed the problem. -- ---------------------------------- E-Mail: Brian Knotts Date: 04-Apr-2001 Time: 14:16:59 This message was sent by XFMail ---------------------------------- From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:30:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34LU1x00394 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:30:01 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LU1M00391 for ; Wed, 4 Apr 2001 14:30:01 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA07550 for ; Wed, 4 Apr 2001 14:28:41 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1368971; Wed, 4 Apr 2001 16:28:39 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA62675; Wed, 4 Apr 2001 16:28:38 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34LV8m09247; Wed, 4 Apr 2001 16:31:08 -0500 Message-Id: <200104042131.f34LV8m09247@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Brian Knotts cc: linux-xfs@oss.sgi.com Subject: Re: chgrp broken by 2.4.3-cvs In-Reply-To: Message from Brian Knotts of "Wed, 04 Apr 2001 14:23:24 PDT." Date: Wed, 04 Apr 2001 16:31:08 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > I haven't seen anything about this, so I thought I'd mention it. There seems > to > be something amiss with groups and the cvs tree as of yesterday. After > installing a kernel compiled from yesterday's cvs, I was unable to chgrp any > files. Reverting to a previous kernel (2.4.2, also from cvs, from Mar 2) fixe > d > the problem. > > -- I though I saw something about this today from Nathan, but I deleted it already, and the mailing list index appears to have stalled. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:39:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34LdWn00831 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:39:32 -0700 Received: from kernelpanix.aura.of.mankind (pD901E3BF.dip.t-dialin.net [217.1.227.191]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LdUM00822 for ; Wed, 4 Apr 2001 14:39:30 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f34LwpI20937; Wed, 4 Apr 2001 23:58:51 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to utz@s2y4n2c.de using -f Date: Wed, 4 Apr 2001 23:58:51 +0200 From: utz@s2y4n2c.de To: Bryan-TheBS-Smith Cc: linux-xfs@oss.sgi.com Subject: Re: XFS heaven Remember: Linus != RedHat Message-ID: <20010404235851.A20460@s2y4n2c.de> References: <3ACB41CC.9C905860@bnl.gov> <3ACB57E0.9EF290B2@theseus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACB57E0.9EF290B2@theseus.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi i'm a sysadm too (all kinds and only unix .-). i want xfs in the stock kernel. but a filesystem has to be rock solid. a fs that makes troble displeased people. they will hate it. i still hate solaris ufs, in the past a 10000+ client webproxy ran into the solaris ufs out-of-fragmentationblocks bug. 4 weeks trouble and only a workaround! the core of xfs is very well tested with irix. but the linux port may have some serious bugs. the linux-xfs people make a very professional job and they tested it very well. but they cannot test all circumstances. until linux-xfs is tested by a large number of different installations, it shouldn't go in the stock kernel. every few weeks i read a announcement on freshmeat for a new jfs drop from ibm. this is marketing! reiserfs was hardly pushed in the stock kernel by its users and developers. it was/is not ready. (has reiserfs a working fsck/repair utility now?) i think/feel linux-xfs is 99.x% ready to go into the offical kernel, _but_ i dont know it. it has to be proven by a lot of installations and waiting some time. there should be more advertisment for linux-xfs. imho xfs is the _best_ fs for linux today, but euphoric should not make blind. please, please dont force it with a crowbar like the reiserfs fans done this. after all, it's linus decision. utz From owner-linux-xfs@oss.sgi.com Wed Apr 4 14:44:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34Liv501096 for linux-xfs-outgoing; Wed, 4 Apr 2001 14:44:57 -0700 Received: from kernelpanix.aura.of.mankind (pD901E3BF.dip.t-dialin.net [217.1.227.191]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LiuM01093 for ; Wed, 4 Apr 2001 14:44:56 -0700 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f34M4hV21001; Thu, 5 Apr 2001 00:04:43 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 5 Apr 2001 00:04:43 +0200 From: utz lehmann To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: chgrp broken by 2.4.3-cvs Message-ID: <20010405000443.A20954@s2y4n2c.de> References: <200104042131.f34LV8m09247@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104042131.f34LV8m09247@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk btw: the mailinglist index should be spilted. it really to big. Steve Lord [lord@sgi.com] wrote: > I though I saw something about this today from Nathan, but I deleted it > already, and the mailing list index appears to have stalled. > > Steve > From owner-linux-xfs@oss.sgi.com Wed Apr 4 15:24:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34MOJi02582 for linux-xfs-outgoing; Wed, 4 Apr 2001 15:24:19 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34MOIM02578 for ; Wed, 4 Apr 2001 15:24:18 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07092 for ; Wed, 4 Apr 2001 15:34:32 -0700 (PDT) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA46045; Wed, 4 Apr 2001 17:23:02 -0500 (CDT) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f34MLvb08485; Wed, 4 Apr 2001 18:21:58 -0400 Message-ID: <3ACB9E85.683BE669@thebarn.com> Date: Wed, 04 Apr 2001 18:21:57 -0400 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Brian Knotts , linux-xfs@oss.sgi.com Subject: Re: chgrp broken by 2.4.3-cvs References: <200104042131.f34LV8m09247@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > > > I haven't seen anything about this, so I thought I'd mention it. There seems > > to > > be something amiss with groups and the cvs tree as of yesterday. After > > installing a kernel compiled from yesterday's cvs, I was unable to chgrp any > > files. Reverting to a previous kernel (2.4.2, also from cvs, from Mar 2) fixe > > d > > the problem. > > > > -- > > I though I saw something about this today from Nathan, but I deleted it > already, and the mailing list index appears to have stalled. > Fixed... oss got and upgraded version of ssh, had to delete old key from knownhosts. etc etc... BTW the list is indexed by month also. http://linux-xfs.sgi.com/projects/xfs/ml.html Never deleted the old monolithic index; probably about time. > > Steve -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. From owner-linux-xfs@oss.sgi.com Wed Apr 4 15:26:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34MQHG02651 for linux-xfs-outgoing; Wed, 4 Apr 2001 15:26:17 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34MQHM02648 for ; Wed, 4 Apr 2001 15:26:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00118 for ; Wed, 4 Apr 2001 15:36:31 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1368755; Wed, 4 Apr 2001 17:24:59 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA07570; Wed, 4 Apr 2001 17:24:59 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34MRTM11167; Wed, 4 Apr 2001 17:27:29 -0500 Message-Id: <200104042227.f34MRTM11167@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: utz lehmann cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: chgrp broken by 2.4.3-cvs In-Reply-To: Message from utz lehmann of "Thu, 05 Apr 2001 00:04:43 +0200." <20010405000443.A20954@s2y4n2c.de> Date: Wed, 04 Apr 2001 17:27:29 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > btw: the mailinglist index should be spilted. it really to big. > > Steve Lord [lord@sgi.com] wrote: > > I though I saw something about this today from Nathan, but I deleted it > > already, and the mailing list index appears to have stalled. > > > > Steve > > Try here: http://linux-xfs.sgi.com/projects/xfs/ml.html Which also gave me the message I was looking for: Date: Tue Apr 3 18:48:37 PDT 2001 Workarea: snort.melbourne.sgi.com:/diskb/build4/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:91641a linux/fs/xfs/xfs_vnodeops.c - 1.495 - fix a silly chgrp bug introduced in the group quota merge. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 4 15:33:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34MXWh02835 for linux-xfs-outgoing; Wed, 4 Apr 2001 15:33:32 -0700 Received: from eem12.resnet.cornell.edu (eem12.resnet.cornell.edu [128.253.247.185]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34MXVM02832 for ; Wed, 4 Apr 2001 15:33:31 -0700 Received: (from eem12@localhost) by eem12.resnet.cornell.edu (8.11.2/8.11.2) id f34MXbK02248; Wed, 4 Apr 2001 18:33:37 -0400 Date: Wed, 4 Apr 2001 18:33:37 -0400 From: Ed McKenzie To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: XFS volume labels Message-ID: <20010404183337.A2201@eem12.resnet.cornell.edu> References: <200104041856.f34IueT02232@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104041856.f34IueT02232@jen.americas.sgi.com>; from lord@sgi.com on Wed, Apr 04, 2001 at 01:56:40PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 04, 2001 at 01:56:40PM -0500, Steve Lord wrote: > It is possible our labeling code got broken, have you tried the uuid > version of the mount? You can also use xfs_db directly to dump this > stuff out: [...] No such luck. The code in mount_by_label.c seems pretty straightforward, though; when I have more time I'll do some debugging. -ed From owner-linux-xfs@oss.sgi.com Wed Apr 4 16:04:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34N47203797 for linux-xfs-outgoing; Wed, 4 Apr 2001 16:04:07 -0700 Received: from dr-zaius.ximian.com (dr-zaius.ximian.com [141.154.95.23]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f34N46M03794 for ; Wed, 4 Apr 2001 16:04:07 -0700 Received: (qmail 7160 invoked by uid 1021); 4 Apr 2001 23:03:46 -0000 Date: Wed, 4 Apr 2001 19:03:46 -0400 From: Michael MacDonald To: linux-xfs@oss.sgi.com Subject: reproducible wedge/corruption Message-ID: <20010404190346.D6693@dr-zaius.ximian.com> Reply-To: mjmac@ximian.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Sender: mjmac@ximian.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all. I've been lurking for a while, trying to get a feel for how XFS is working for people. It seems to be working well overall, which is a little disappointing for me because I'm not having much luck with it. Perhaps I'm not living right, or something. Anyhow, I have two machines with similar hardware on which I can pretty reliably cause the system to lock solid. I've tried different kernels (linux-xfs-beta vs. linux-xfs; 2.4.1 -> 2.4.3), but the problem doesn't go away. The kernel is configured with the bare minimum to run an IDE-based server. To try to reproduce the error that users were running into, I wrote a simple script to pound on the fs. It hasn't made it past the first or second iteration on an XFS partition, because the machine will hang. Can't log in at the console or anything. I tried changing the logbsize parameter as described in the FAQ, and got better performance until the machine hung like it did before. I gave up after several days of tweaking and reformatted ext2. I would wonder if I have something misconfigured except for the fact that the script runs through all 30 iterations on an ext2 filesystem without a hang. I'll post the script if requested, but basically all it does is: create 10000 small files in one directory make 10000 symlinks in another directory to the files in the first remove the second directory remove the first directory It seems to be hanging mostly during the removal stage, although I have seen it hang during file creation. On two of the hangs, I have seen some nasty file corruption. The specifics of the system are as follows: Dell PowerEdge 350 Celeron 600 128MB RAM Intel 440BX chipset I've got another 350 with PIII 700 512MB RAM They both seem to exhibit similar behavior wrt XFS, although I haven't pounded on the second one quite as much. If anyone has any ideas, or would like more details, please let me know. I would really like to get XFS on these things, as they've got a lot of disk between the two of them. -- Michael MacDonald Systems Monkey mjmac@ximian.com Ximian, Inc. From owner-linux-xfs@oss.sgi.com Wed Apr 4 16:10:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34NADw04060 for linux-xfs-outgoing; Wed, 4 Apr 2001 16:10:13 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34NACM04053 for ; Wed, 4 Apr 2001 16:10:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA21262 for ; Wed, 4 Apr 2001 16:08:56 -0700 (PDT) mail_from (dxm@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA14597 for ; Thu, 5 Apr 2001 09:08:32 +1000 (EST) Message-Id: <200104042308.JAA14597@snort.melbourne.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: linux-xfs@oss.sgi.com X-URL: http://zoic.org/dxm Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Apr 2001 09:08:32 +1000 From: Daniel Moore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk repeatable assertion trip in qa 017. XFS assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: xfs_trans.c, line: 335 kernel BUG at debug.c:48! Entering kdb (current=0xc752c000, pid 7515) on processor 0 Oops: invalid operand due to oops @ 0xc8880d7d eax = 0x0000001a ebx = 0xc5485ba0 ecx = 0x00000001 edx = 0x00000001 esi = 0xffffffff edi = 0xc752db60 esp = 0xc752d930 eip = 0xc8880d7d ebp = 0xc752d93c xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010282 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc752d8fc [0]kdb> bt EBP EIP Function(args) 0xc752d93c 0xc8880d7d [xfs_support]assfail+0x2d (0xc89200a0, 0xc891fef6, 0x14f) xfs_support .text 0xc8880060 0xc8880d50 0xc8880d84 0xc752d958 0xc88eead6 [xfs]xfs_trans_mod_sb+0x142 (0xc5485ba0, 0x4, 0xffffffff) xfs .text 0xc8886060 0xc88ee994 0xc88eec30 0xc752d974 0xc8892630 [xfs]xfs_alloc_ag_vextent+0x278 (0xc752db60) xfs .text 0xc8886060 0xc88923b8 0xc889264c 0xc752d9a0 0xc8895131 [xfs]xfs_alloc_vextent+0x3c1 (0xc752db60) xfs .text 0xc8886060 0xc8894d70 0xc889525c 0xc752dbb0 0xc88a54ac [xfs]xfs_bmap_alloc+0x1930 (0xc752dce0) xfs .text 0xc8886060 0xc88a3b7c 0xc88a577c 0xc752dd2c 0xc88a9790 [xfs]xfs_bmapi+0x884 (0xc5485ba0, 0xc6b74940, 0x29, 0x0, 0x1) xfs .text 0xc8886060 0xc88a8f0c 0xc88aa8b8 0xc752de6c 0xc890524d [xfs]xfs_strategy+0x729 (0xc6b74958, 0x29000, 0x0, 0x1000, 0x10002) xfs .text 0xc8886060 0xc8904b24 0xc8905698 0xc752dea0 0xc8903183 [xfs]linvfs_pb_bmap+0x63 (0xc18e29e0, 0x29000, 0x0, 0x1000, 0xc752dee0) xfs .text 0xc8886060 0xc8903120 0xc8903190 0xc752defc 0xc887a954 [pagebuf]pagebuf_delalloc_convert+0x44 (0xc18e29e0, 0xc10d70b4, 0x10002, 0xc8903120) pagebuf .text 0xc8876060 0xc887a910 0xc887aa00 0xc752df40 0xc8879641 [pagebuf]pagebuf_write_full_page+0x69 (0xc10d70b4, 0xc8903120) pagebuf .text 0xc8876060 0xc88795d8 0xc8879764 0xc752df50 0xc8903341 [xfs]linvfs_write_full_page_nounlock+0x11 (0xc10d70b4) xfs .text 0xc8886060 0xc8903330 0xc8903350 0xc752df68 0xc013356c _write_buffer+0x7c (0xc6578420, 0xc752c000) kernel .text 0xc0100000 0xc01334f0 0xc01335c0 0xc752df98 0xc0133776 sync_buffers+0x1b6 (0x0, 0x0) kernel .text 0xc0100000 0xc01335c0 0xc01337c4 0xc752dfb0 0xc0133801 fsync_dev+0x11 (0x0) kernel .text 0xc0100000 0xc01337f0 0xc0133884 0xc752dfbc 0xc013388e sys_sync+0xa (0x804ec28, 0x65d12b9a, 0x65d12b9a, 0x4000ae60, 0xbffffb2c) kernel .text 0xc0100000 0xc0133884 0xc0133894 0xc01070d7 system_call+0x33 kernel .text 0xc0100000 0xc01070a4 0xc01070dc ----------------------------------------------------- Daniel Moore dxm@sgi.com R&D Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Apr 4 16:10:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34NADl04061 for linux-xfs-outgoing; Wed, 4 Apr 2001 16:10:13 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34NACM04055 for ; Wed, 4 Apr 2001 16:10:12 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA21266 for ; Wed, 4 Apr 2001 16:08:57 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1368191; Wed, 4 Apr 2001 18:08:55 -0500 (CDT) Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA71140; Wed, 4 Apr 2001 18:08:55 -0500 (CDT) Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f34NBOZ12105; Wed, 4 Apr 2001 18:11:24 -0500 Message-Id: <200104042311.f34NBOZ12105@jen.americas.sgi.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mjmac@ximian.com cc: linux-xfs@oss.sgi.com Subject: Re: reproducible wedge/corruption In-Reply-To: Message from Michael MacDonald of "Wed, 04 Apr 2001 19:03:46 EDT." <20010404190346.D6693@dr-zaius.ximian.com> Date: Wed, 04 Apr 2001 18:11:24 -0500 From: Steve Lord Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please post your script - and if anyone else is lurking with problems please tell us about them too (provided they are XFS problems and not 'Childhood Issues' to quote Larry McVoy)! Steve > Hi all. I've been lurking for a while, trying to get a feel for how XFS > is working for people. It seems to be working well overall, which is a > little disappointing for me because I'm not having much luck with it. > Perhaps I'm not living right, or something. > > Anyhow, I have two machines with similar hardware on which I can pretty > reliably cause the system to lock solid. I've tried different kernels > (linux-xfs-beta vs. linux-xfs; 2.4.1 -> 2.4.3), but the problem doesn't > go away. The kernel is configured with the bare minimum to run an > IDE-based server. > > To try to reproduce the error that users were running into, I wrote a > simple script to pound on the fs. It hasn't made it past the first or > second iteration on an XFS partition, because the machine will hang. > Can't log in at the console or anything. I tried changing the logbsize > parameter as described in the FAQ, and got better performance until the > machine hung like it did before. I gave up after several days of > tweaking and reformatted ext2. I would wonder if I have something > misconfigured except for the fact that the script runs through all 30 > iterations on an ext2 filesystem without a hang. > > I'll post the script if requested, but basically all it does is: > create 10000 small files in one directory > make 10000 symlinks in another directory to the files in the first > remove the second directory > remove the first directory > > It seems to be hanging mostly during the removal stage, although I have > seen it hang during file creation. On two of the hangs, I have seen > some nasty file corruption. > > The specifics of the system are as follows: > Dell PowerEdge 350 > Celeron 600 > 128MB RAM > Intel 440BX chipset > > I've got another 350 with > PIII 700 > 512MB RAM > > They both seem to exhibit similar behavior wrt XFS, although I haven't > pounded on the second one quite as much. > > If anyone has any ideas, or would like more details, please let me > know. I would really like to get XFS on these things, as they've got a > lot of disk between the two of them. > -- > Michael MacDonald Systems Monkey > mjmac@ximian.com Ximian, Inc. From owner-linux-xfs@oss.sgi.com Wed Apr 4 16:12:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34NCWi04143 for linux-xfs-outgoing; Wed, 4 Apr 2001 16:12:32 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34NCWM04140 for ; Wed, 4 Apr 2001 16:12:32 -0700 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA01717 for ; Wed, 4 Apr 2001 16:12:30 -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 JAA06038; Thu, 5 Apr 2001 09:10:53 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA24634; Thu, 5 Apr 2001 09:10:52 +1000 (EST) From: "Nathan Scott" Message-Id: <10104050910.ZM24677@wobbly.melbourne.sgi.com> Date: Thu, 5 Apr 2001 09:10:51 -0500 In-Reply-To: Ed McKenzie "Re: XFS volume labels" (Apr 4, 6:33pm) References: <200104041856.f34IueT02232@jen.americas.sgi.com> <20010404183337.A2201@eem12.resnet.cornell.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ed McKenzie Subject: Re: XFS volume labels Cc: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Apr 4, 6:33pm, Ed McKenzie wrote: > Subject: Re: XFS volume labels > > On Wed, Apr 04, 2001 at 01:56:40PM -0500, Steve Lord wrote: > > It is possible our labeling code got broken, have you tried the uuid > > version of the mount? You can also use xfs_db directly to dump this > > stuff out: > [...] > > No such luck. The code in mount_by_label.c seems pretty > straightforward, though; when I have more time I'll do some debugging. > fwiw, I use mount-by-label on several XFS filesystems on my development machine with no problems (have done so for several months now). This was first in util-linux 2.10r, so sounds like you do indeed have the right code base (there have been no changes in this area in subsequent releases, ext2 and xfs have the same code now as they did in 2.10r). Can you give more details on the exact problem? (your fstab entry, xfs_db "sb" output, etc). does it fail when you use "mount -L